#Zambo

1 messages · Page 1 of 1 (latest)

rare wharfBOT
lusty forge
#

Hello! What type of connected accounts are you using (Standard, Express, or Custom)?

obtuse jacinth
#

They are all Standard accounts

lusty forge
obtuse jacinth
#

So we had originally tried to set up the implementation using direct charges, however we had issues getting this to work with SCA - when we set up the frontend flow for handling SCA with our platform account API keys, SCA would always fail

lusty forge
#

Direct charges are the way to go here, and SCA should work fine with them. I'd be happy to help you get the frontend piece working. Is this with Stripe.js?

obtuse jacinth
#

Stripe.js + Elements with a manual confirmation flow

lusty forge
#

Perhaps you were not doing that, which led to the errors?

#

If you were doing that, can you share the error message(s) you were seeing?

obtuse jacinth
#

So, the way that we attempted to use the stripeAccount option in our flow was to create Customer and PaymentMethod on our platform account, then attempting to create PaymentIntents on our connected accounts. The errors that we were seeing with those attempts for the integration were around our PaymentMethods and Customers not existing on the Connected accounts. It seemed kind of crazy to try to manage cloning them and managing them across accounts

lusty forge
#

The recommended approach there is to mostly do what you describe, but clone as-needed to the connected accounts. You keep the Customers and their Payment Methods on your platform, but then when you want to create a payment on a connected account you clone the Payment Method to the connected account and create a Payment Intent there. No Customer on the connected account is required, and the cloned Payment Method can only be used a single time, so you don't have to clean up after the payment is made.

obtuse jacinth
#

So with our use case, we are storing payment information and collecting initial payments, which we then make several followup payments off session for the user to pay off their balance. With this flow, the subsequent payments all required SCA and would fail as we were trying to make those off session

lusty forge
#

Are you using a Setup Intent on your platform to set up the Payment Methods for future use?

obtuse jacinth
#

We have a couple of different flows, some which involve only adding a payment method, which we use a Setup Intent for. We have other flows where we complete an initial payment that just use a Payment Intent with setup_future_usage set for off_session payments

lusty forge
#

Okay, that sounds good. The setup you perform on your platform will carry over to the cloned Payment Methods on the connected accounts.

#

However, what country is your platform account in?

obtuse jacinth
#

USA

lusty forge
#

Ah, that's the issue. The setup performed on a US account is not sufficient for SCA-impacted countries. You would need to perform setup on an account in one of those countries instead.

obtuse jacinth
#

So originally set up this Connect integration so that we could process payments for our entities across US, UK/Europe, and Canada with the ability to process payments and payouts without being hit with conversion fees in each respective region, with the US account as the platform account

#

Is the recommendation then that we change our platform account to be a Canada or UK account, and reconnect the other accounts to that account?

nocturne cypress
#

👋 stepping in as Rubeus needed to step away.

#

Catching up

obtuse jacinth
#

Would that affect our ability to accept USD via this integration? IIRC a US account was requisite for USD payouts

nocturne cypress
#

So yeah, you could change your platform to an EU platform and then clone to a US account for instance. That would help ensure cards are set up to handle SCA.

#

So the other option though is to use a SetupIntent OBO of one of these Connected Accounts in Europe when you set up the card

#

That would also ensure that SCA is handled when setting it up, before cloning it.

obtuse jacinth
#

So we tried using the on_behalf_of parameter as per the original message in this thread, but we didn't see any indication that the money was going to the correct account in the dashboard

#

Our current iteration of attempting to get this to work uses on_behalf_of, and we have all of our flows working correctly, but everything appears to be happening on the platform account and there's no indication that payments/charges are being routing to the appropriate account

nocturne cypress
#

Correct, you would only use on_behalf_of to set up the card, then you would clone it to the necessary account and charge it on that account

obtuse jacinth
#

So are we able to create a SetupIntent from our US platform account with on_behalf_of referencing our Canadian account, then create PaymentIntents for direct charges to our platform account (USD), or connected accounts (CA/CAD, UK/GBP)? Eg, should we be using the Canadian account as the setup account for all payment methods so that they support SCA, and will we keep the flexibility of being able to charge with any account and currency after storing the Payment Method?

nocturne cypress
#

Well SCA is mostly EU-focused. So I would recommend setting it up with an EU account which will force 3DS to be completed (if necessary), then yes you should be able to clone it successfully to any of your Connected Accounts and charge in that desired currency.

obtuse jacinth
#

Would a UK account check the box for this? We use a UK account/entity to serve EU currently

nocturne cypress
#

Yes I believe it would since SCA is also enforced in UK

obtuse jacinth
#

Okay thanks for the assistance, it sounds like this approach should cover all of our use cases. I'd just point out that it's really easy to read the docs and see on_behalf_of and assume that will take care of all of the cross-account payment method / payments management, but it's a bit less simple than that. 🙂