#Gizmo-Elements

1 messages · Page 1 of 1 (latest)

frank pewter
#

👋 happy to help

woven orchid
#

Thank you, tarzan

frank pewter
#

is there any particular reason why you don't want to use the recommended Payment Elements?

woven orchid
#

I'm trying to capture the payment method to be used later so that I can use it for both a one-time charge and to setup a subscription

frank pewter
#

you could do so with SetupIntents and Payment Elements

woven orchid
#

It looks like you can do this if you pass in an explicit cardElement, but I don't know how to do it by passing in a PaymentElement

frank pewter
#

using the Card Element is not recommended because it doesn't support SCA (3DS, etc)

woven orchid
#

Thank you. So it looks like it's just a matter of calling confirmSetup instead of confirmCard

frank pewter
#

yes but again I strongly recommend you use the Payment Element instead of the Card Element

woven orchid
#

Got it, thanks. I meant switching to use the Payment Element was just a matter of calling confirmSetup on a PaymentElement instead of ConfirmCard on a CardElement.

frank pewter
#

yes

woven orchid
#

I'm not actually storing the card so that I can charge against it in the future as the text on the PaymentElement suggests, By providing your card information, you allow ... to charge your card for future payments in accordance with their terms..

I'm only doing it so that I can both make a one time charge and optionally create a subscription for the user if they chose a subscription add-on at checkout. Is there any way to suppress this message?

frank pewter
#

not really

woven orchid
#

Is there a better way to do what I'm trying to do than storing the payment method in that case? I think telling customers I'll be able to charge them for more later may scare them away,

frank pewter
#

you could basically use Payment Intents if you're charging directly and use the setup_future_usage field to save the payment details

woven orchid
#

Thanks, would that not display the message about allowing me to charge the card for future payments?

frank pewter
#

actually it will still give the same message

woven orchid
#

Oh. Is there any way to charge for a one-time charge and create a subscription without displaying that message?

frank pewter
woven orchid
#

Thanks. So for this I would need to already have a customer. This won't display the message about allowing future charges to the user?

frank pewter
#

since you are doing a recurring payment (through a subscription) the message wouldn't be a problem, right?

woven orchid
#

Yeah I suppose it wouldn't. I was thinking about the case where a visitor doesn't choose the subscription add-on at checkout, but I suppose I could setup a different PaymentIntent for that scenario.

#

Is there a way to create the customer at the same time as I create the subscription, since a first time customer at my site wouldn't have a corresponding Stripe customer yet?

frank pewter
#

actually what you can do is decide whether you create a PaymentIntent or create a Subscription with the add_invoice_items and use the latest_invoice.payment_intent

#

you can create the customer before creating the subscription on the backend

woven orchid
#

So you would create the customer prior to trying to charge the customer on the assumption the charge will go through, as opposed to creating the customer only after a successful charge?

frank pewter
#

for subscriptions yes

woven orchid
#

Got it, thanks. Do you guys offer any kind support I can pay for so I can share my screen / go over exactly what I'm trying to do and confirm I'm implementing the right solution with Stripe?

light schooner
woven orchid
#

Thanks, I guess I'm looking for something more like an experienced Stripe developer who knows what they're doing to pair with me for a bit. Is there anyone you can recommend if Stripe doesn't offer it themselves?

light schooner
#

well you can ask us questions directly here on Discord, we can't pair with you like that since we don't have the capacity but if you're stuck with anything you can share some code here and we can look.
Nobody I can recommend in particular no, https://stripe.com/partners/directory?t=Consulting is a directory of some agencies we certified.

woven orchid
#

Thank you. I was able to implement Braintree, I should be able to implement Stripe so I'll keep at it.

Can you confirm that if I have 2 scenarios where:

  1. Sometimes a visitor checks out with only a one-time payment; and
  2. Sometimes a visitor checks out with both a one-time payment and a subscription

I should conditionally

  1. In the case of only a one-time payment: Use a PaymentIntent; or
  2. In the case of a one-time payment and a subscription: Create a Subscription with an invoice item added to it for the one-time payment, and use the Subscription's PaymentIntent in my checkout

?

light schooner
#

yep, that's what I would do, you'd branch the integration and either do a PaymentIntent flow directly creating the PI, or a Subscription with an added invoice item.
I assume you can't use Checkout for some reason? that would make it a bit easier. But yep, what you describe is the right approach

woven orchid
#

Thanks for confirming. Regarding using Checkout, I just thought redirecting visitors to Stripe for checkout would have a less-than-premium feel for visitors. No offense intended to Stripe, it just doesn't seem to be what most big brands do.

#

For adding the invoice item to the Subscription, does the "product" need to be setup in Stripe in order for this to work?

add_invoice_items.price_data.product
REQUIRED
The ID of the product that this price will belong to.```
https://stripe.com/docs/api/subscriptions/create#create_subscription-add_invoice_items-price_data-product

What can I do if the price of the one-time charge can vary depending on customizations the visitor has selected?
light schooner
#

yes you need a product. If the amount differs you can use price_data to create the amount ad-hoc

#

if you need the Product to be different you'd just create one with an API call before creating the subscription. The product's description is what appears in the invoice line item, which is the main reason for wanting to use different ones. Otherwise you can just create some default "One time setup fee"-description Product and use that with ad-hoc unit_amounts in price_data, whatever works for you

woven orchid
#

Got it, thank you. I've been emailing customers receipts I generate with my application. Will customers receive receipts from Stripe as well?

light schooner
woven orchid
#

Thanks, so it's optional and I can continue to use my website's receipts, correct?

light schooner
#

you can disable it from your settings and send your own receipts by e.g. listening to wehooks about successful payments and triggering your own email system, yep

woven orchid
#

Thank you. Regarding listening for webhooks, is there a way I can get payment confirmation synchronously so I'd know whether the payment was successful before giving the customer access to my application?

light schooner
#

you can but it wouldn't be reliable

#

like what if the customer closes their browser immediately after paying or their wifi connection drops or whatever. These are real things that happen, and if you rely on your frontend to notify you of the payment completing you will miss some payments and not provision the service, webhooks are needed as a backup

woven orchid
#

Hmm, how could i ensure payment went through before giving customers immediate access to the software upon payment in that case?

light schooner
#

you'd give them access when handling the e.g. payment_intent.suceeded webhook event that's generated

woven orchid
#

Currently when the customer submits the "confirm payment" form, the payment happens synchronously on the backend via Braintree and they are redirected to the appllication that paying customers see. Do you have any suggestions what should happen to the customer after paying with the Stripe model that relies on webhooks?

light schooner
woven orchid
#

How do/can they know when their access to the site has been provisioned (because I received the Stripe webhook) in that case?

light schooner
#

you said you're going to email them

#

like, on the backend, you get a webhook from Stripe, you reconcile things, update your database, give them access to the product, and email them

woven orchid
#

I email them a receipt but they're currently just redirected to the application immediately after payment. Is there no way to achieve the same via Stripe?

light schooner
#

you can also kick off that process from the frontend if you like, have the frontend notify the backend to ask it to retrieve the payment details and do the reconciliation process

#

if you want the best flow that's the way to do it, have a "fulfil order" function on your backend, that can be called idempotently either by your frontend on the redirect, or by a webhook handler, and it works and does the right thing regardless of which one calls it or if it's called by both

light schooner
#

for completeness the escape hatch for platforms that are rigidly stuck to the "frontend calls backend with a payment token, backend does the payment and everything else" is https://stripe.com/docs/payments/accept-a-payment-synchronously but it's not the recommended integration since it only works for cards(and is not compatible with the PaymentElement). The Stripe integration is built on the concepts of client-side payment processing, with multiple payment methods(many of which can involve redirects to external banks etc) and the use of webhooks to drive order fulfillment; we very intentionally pivoted away from the sync token->charge model in 2019 with PaymentIntents, since the current model is more flexible and works better for local payment methods and card authentication like 3D Secure and other developments in the industry.

#

hopefully that's useful context. Anyway, we try to answer specific coding/API questions here so I'd suggest playing around with the integration a bit and coming back with anything that's unclear