#benk

1 messages · Page 1 of 1 (latest)

unkempt lindenBOT
crude basalt
#

there's other advantages to using Checkout etc as they support multiple payment methods and we optimise them for conversion and so on. But if you really do want to use your own form and can handle the PCI side, then it's possible.

fading mauve
#

thank you

#

yes we are PCI Level 1 and do the SAQ D every year, there is no problem

#

Our company also internally discussed another requirement for the Connected Account setup which was onboarding. The Stripe documentation mentions that us as a platform need to initiate the onboarding and handle the checks for whether the onboarding has been completed. We already have existing Stripe clients but they do not have the Connected Account. For these existing clients do we have to go through the onboarding again, specifically to create the Connected account for these existing clients?

crude basalt
#

in general though we'd recommend using the same flow for users who have existing accounts and who don't and onboarding the same

fading mauve
#

the link above would still mean certain friction for existing clients to be setup and is something we need to discuss

#

we are setting up revenue-sharing agreement with Stripe and we want to minimize the friction for existing clients of ours

crude basalt
#

yeah these are all topics you'd want to discuss with the people you're working with from our Sales side I'd imagine as they can give you more tailored advice for your specific set up, especially as you have requirements like wanting a raw PAN integration

#

but happy to try give some general information

fading mauve
#

yes we have a Stripe connection and we were told to get more technical details over here in terms of the technical requirements

crude basalt
#

yeh unfortunately those teams keep sending folks here, we're trying to get more clarity internally shared. Your contact should help you and proxy your questions if they don't know. This is not a a dedicated place where we can have a long running discussion with your very specific requirements, it's more an anonymous chatroom for questions and help with the API!
To be clear anyway, happy to answer anything specific you have like your existing questions, it's no problem

fading mauve
#

thanks karllekko

#

we are just trying to understand how to get this working with minimal interruption for existing clients and how best to fit in in our platform

crude basalt
#

well really it depends what your Connect set up would look like (would you generally be using Standard/Express/Custom accounts) and how much control you want over them and what charge flow you'd use. As I mentioned, you can connect Standard accounts to your platform over OAuth, but then maybe you'll end up with a mixture of Standard and Express accounts which can cause confusion/problems later. I'd highly suggest anyway not using different flows for new and existing users, use the same flow and create fresh accounts, taking advanage of the legal entity sharing feature my link described.

fading mauve
#

for us it was really the main requirement that we would be able to continue using our own payment page (no Checkout, Payment Elements) since we are PCI Level 1 and so minimize interruption both in development and user experience. We were told by Stripe that for the revenue-sharing we would need to use Connect Standard.

#

would the existing tokens of existing clients work with the new Connect Standard accounts? Similarly what happens to the historical transactions processed so far by existing clients?

crude basalt
#

would the existing tokens of existing clients work with the new Connect Standard accounts?
depends how they integrate(d). Maybe they don't have any saved card details(you can integrate by just taking card details and doing one-off charges, so they might not have saved anything in their Stripe accounts). If they do exist then I believe if you connect to them with OAuth with read_write scope you can access and charge those saved payment method details in our API. You can not access the raw card details themselves. But going back to my previous point, AFAIK we are slowly deprecating read_write access to existing accounts in favour of having you create new accounts under the same "user" with separated data , per the link I shared earlier. Worth clarifying with your contact.
what happens to the historical transactions processed so far by existing clients?
nothing

fading mauve
#

we do process recurring payments as well, so the tokens are being utilised for these clients of ours. Are these tokens also available on the platform with the newly Connected accounts?

crude basalt
#

not entirely sure what you mean by that. But there are ways you can collect payment details on a platform account and then "clone" them to connected accounts, so you can charge them on behalf of both accounts

fading mauve
#

yes, my question is specifically about whether the current existing tokens created and used on a non-Connect setup can be used on the Connected account setup. Given that the Connect accounts requires a new onboarding one would think that perhaps these are 2 different sets of "platforms" with separated visibility of transactions and tokens

crude basalt
#

I guess how I'd summarise it is

  • if you use OAuth with read_write to connect your platform to some existing full Stripe merchant account, you have complete access to anything they have in their account like saved PaymentMethod objects and Customer details and such. You can initiate charges on those saved details on behalf of the connected account. You can't copy those details 'up' to your platform for you to use directly.
  • if you use the recommended integration (https://stripe.com/docs/connect/standard-accounts) where you create new Stripe merchant account objects for each user(and if they have an existing account, we make the onboarding easier), you get a brand new account connected that is scoped just to your platform, and none of existing saved objects the user might have on their other Stripe accounts comes over.

As I mentioned, we are slowly deprecating the first approach in many ways, as mentioned in the call out box in https://stripe.com/docs/connect/oauth-standard-accounts

fading mauve
#

ok, makes sense that there are certain separations between these platforms and the related payment objects as you described (they are essentially on different accounts). But just for clarification you can clone the old platform payment objects onto the new Connected Account right?

crude basalt
#

if you have saved payment methods on your platform, you can clone those 'down' to connected accounts of any type and age yes

#

I have to run for now, my colleague @sleek cobalt is here too

fading mauve
#

cool thanks for all the help karllekko!

sleek cobalt
#

Hi! I'm taking over this thread. Let me know if you have other questions.

fading mauve
#

hi soma

#

I have a follow-up question on the cloning of payment objects discussed with your colleague.

#

when we are talking about the possibility of cloning it, do we have to have the full PaymentMethod object itself or is it enough to have the id itself for cloning the object onto a different platform?

sleek cobalt
fading mauve
#

ok great!

#

I think I have to read through and understand a bit more about our needs for now

#

thanks both of you for all the knowledge and answers here it was really useful

#

have a nice day!

sleek cobalt
#

Happy to help 🙂