#peter-payments

1 messages · Page 1 of 1 (latest)

supple grail
#

hi! well the easiest way to accept multiple payment methods is Checkout. Alternatively you can use the PaymentElement yes. So either approach from the two tabs at https://stripe.com/docs/payments/accept-a-payment

If you currently use server-side confirmation (https://stripe.com/docs/payments/accept-a-payment-synchronously) that only works for cards and you should stop using that and move to the recommended asynchronous flows with webhooks.

webhooks are sent straight away but the way you should do it is you can show the customer an initial "thank you" page when they are redirected to your page after the payment on the frontend, and create the database order/emails for the customer when the webhook arrives.

stuck drift
#

Ok

#

We also have some edge cases...

#

1/ A customer can setup a subscription and pay for items at the same time

#

2/ We sometimes have payments which go to different connected accounts (using direct charges). For this, we create the payment method on our account and share it with the platform

#

Presumably, in these scenarios, we would still have to work the way we do?

supple grail
#

hmm. Well 1/ that's fine, I don't see how that would be impacted by any changes here. 2/ that whole idea of cloning payment methods to connected accounts only works for cards and not other payment methods so you can't use that approach for Direct Charges, you have to process the whole payment on the connected account and create the PaymentMethods there directly

stuck drift
#

Right

#

Can you list them steps from 1 in what we should do in this scenario

#

If setting up a subscription, we currently save the customer, attach the PM, then confirm the paymentIntents using the customer as payment then finally setup the subscription

#

If using the paymentElement, can this be done?

#

Stripe changes every time we look at the docs 😄

supple grail
#

IMO you should just use Checkout here rather than Elements and save yourself a lot of headaches

stuck drift
#

Checkout asin the stripe solution

#

as in*

#

How wil checkout make this easier?

supple grail
stuck drift
#

We are keen to keep this integrated with out system. We use Stripe connect

#

We already have it working today, but wondered if doing it using the paymentElement would be better

supple grail
# stuck drift How wil checkout make this easier?

well for example " we currently save the customer, attach the PM, then confirm the paymentIntents using the customer as payment then finally setup the subscription" could be replaced with "create Session, redirect, done",and the same code would work for multiple payment methods and not just cards.

But it is completely possible to not use Checkout, it's just a bit more complex. Happy to try to help but it's hard to talk in abstract.

supple grail
#

today you probably do things the old way where you use Elements on the frontend, create a Token or PaymentMethod, send that to your backend and then process the payment there

#

PaymentElement and all our integrations today do not work that way, instead you create the PaymentIntent first on the backend, pass it to the frontend to initialise the UI, and then complete the payment on the frontend.

#

ultimately if you want an extensible payment flow that you can add multiple payment methods to, you have to switch to that model(and then can use PaymentElements or Checkout), the "send tokens to the backend" integration mode is a cards-only traditional flow

stuck drift
#

Right ok

#

Whats the bet way to talk this through

supple grail
#

I think we are doing that now

stuck drift
#

ha

#

Ill list out our scenarios

#

1/ Most common - a direct charge on a connected account

#

2/ Rare - customer enters card details once, we charge on 2 or more connected stripe accounts

#

3/ Common - customer signs-up to a scription which has a trial period. We make an initial charge and also setup the scubscription

#

If we have to removie scenario 2, im ok with that

supple grail
#

I don't see any reason to remove any of them, those are all possible and supported flows

#

now it is I suppose more complicated because in a cards-only integration you can just collect the card token, send it your backend, and then branch into one of those paths from there. That kind of approach doesn't really scale to other payment methods though so it gets more complicated to out things together

stuck drift
#

This is why I thought scenario 2 would be the one to "go" in the short term if we change to this approach

supple grail
#

IMO the easiest ways for what you say are

1/ https://stripe.com/docs/connect/creating-a-payments-page?ui=checkout , use Checkout with the StripeAccount option, extremely easy.
2/ There's not really any clean way of doing this. Do you process the payments as one big payment, or do you really want "collect payment details; charge them once on account A, charge them again on account B; all at the same time"?
3/ https://stripe.com/docs/billing/subscriptions/checkout you can pass line_items with a recurring price and a non-recurring one(for the one-off initial charge) and subscription_data[trial_period_days] and it will do what you want

stuck drift
#

In items 3, do the line_items need to be products already in the system?

#

Scnario 1/ We dont want to/cant direct them elsewhere

#

So Checkout is not an option

supple grail
supple grail
stuck drift
#

and how can this be used to setup a subscription and also make a payment?

#

It seems easy to just make payments

supple grail
#

the PaymentElement just takes a PaymentIntent

#

that can be one you create directly

stuck drift
#

What about both subscription setup and a payment

supple grail
stuck drift
#

I thought that related to Checkout?

supple grail
#

my last 4 messages are not about Checkout

#

they are replying directly to "how to use PaymentElement to create a Subscription + take a one-time payment"

stuck drift
#

with the line_items?

supple grail
#

I didn't mention line_items in those messages

stuck drift
#

Sorry, I am confused

supple grail
#

if you want scenario 3 without Checkout, it's

supple grail
stuck drift
#

Got it, but the inital charge is always different

supple grail
stuck drift
#

Stripe::Subscription.create({
customer: '{{CUSTOMER_ID}}',
items: [{
price: '{{ RECURRING_PRICE_ID }}',
}],
add_invoice_items: [{
amount: 200,
}],
payment_behavior: 'default_incomplete',
})

#

Like this?

supple grail
#

what are you asking exactly?

#

that's the example code from the docs I linked , yes

stuck drift
#

I changed the add_invoice_items block

supple grail
#

ah I see

#

No, that doesn't work since add_invoice_items doesn't allow for the direct ad-hoc amount to be passed(it's not in https://stripe.com/docs/api/subscriptions/create#create_subscription-add_invoice_items) . Sorry, but the API tries to heavily push you to using Prices/Products so your catalogue is in your account to make reporting easier.
You could change it to

add_invoice_items: [{
    unit_amount: 200, currency:"eur", product:"prod_xxx"
  }],

but you need an existing Product. Or you could, instead of using add_invoice_items , call https://stripe.com/docs/api/invoiceitems/create#create_invoiceitem-amount to create an item first, then create the subscription(it will pull the pending item in automatically, but add_invoice_items is meant to be a nicer-to-use shortcut then creating the item separately).

stuck drift
#

Right, so the product might be "one off charge"

#

with no price associated to it

#

and then we set the unit_amount when required?

supple grail
#

yes

stuck drift
#

Right

#

So in this scenario

#

1/ Create a customer

#

2/ Create a subscription

#

2a/ When creating the subscription add any additional payments OR create a invoice item before the subscription

#

3/ Get the latest invoice and sent the payment intents client secret to front end

#

4/ confirmPayment

#

5/ wait for webhooks to come in confirming the subscription is setup and the payments have been made

supple grail
#

yep!

stuck drift
#

How do we know what payment type they used?

#

i.e. lets say they used a card, and this then expires

#

would we present them with the paymentElement again, but using the p_i from the failed subscription payment?

supple grail
supple grail
stuck drift
#

Ok

#

And the other scneario is muhc easier

#

1/ create a pyement intent

#

2/ pass client secret to front end

#

3/ collect payment from the paymentElement

#

4/ listen for webhook

supple grail
#

for a simple one-time Direct charge, yes (note you need to pass Stripe-Account when creating the PaymentIntent and when initialising the Stripe library on the frontend as I mentioned), that's the flow!

stuck drift
#

Great

#

Super helpful

#

We have work to do!

#

We already process nearly $500,000 a month in volume via connect