#alexmorese-obo-pm
light hare
cards
I've been cloning them for use on connected account forever, but am updating some of our api usage
using 4000 0025 0000 3155 to get an sca-alike prompt customer side
created with setup_future_use and charging with off_session
junior merlin
do you have example IDs of
1/ you setting up the card
2/ cloning the card
3 / using it on the Connect account
so I can see what error you get
light hare
yes
original intent pi_3JygTM2XfSrS28zR041GOVCq
created customer to save payment method to on primary account cus_KdyQErMT6Rah28 method is pm_1JygTm2XfSrS28zR7akJXCqr
cloned method on connected account pm_1JygTx4GwvMfm2gzGQpfDfGO
attempted payment intent on connected account pi_3JygTy4GwvMfm2gz0I27Gtjm
junior merlin
thanks, looking
ah I think I know
that original PaymentIntent on the Platform: pi_3JygTM2XfSrS28zR041GOVCq
it was never captured
try that, fully capture the first PaymentIntent
then doing everything else, i.e. clone and create a PaymentIntent on the Connect account
light hare
aha, dang ok. Will give that a go
IS there an alternative path using those on_behalf_of type flags and not cloning?
junior merlin
@light hare so it depends, when you use the "cloning" approach, you are creating a Direct Charge, meaning it lives on the Connect account
With o_behalf_of, you create a Destination Charge (that lives on the Platform), a significantly different fund flow.
So while yes o_b_o won't require cloning, it will change the fund flow fundamentally, just letting you know
light hare
I believe I have to do the originating method via the o_b_o so that I can capture/properly store
silent horizon
If you're cloning the Payment method to the connect account, there isn't any need to use OBO. OBO is more useful when the Payment Method isn't stored on the Connected account at all.
light hare
yeah that's what I'm going for. We create the customer record on us (marketplace) then it's usable on connected accounts, but we don't store the customer there, and it's a consumed method.
works great generally but hit this edge testing a 3dsecure # and I believe apple pay is doing similar behavior, google doesn't complain though
It's fantastic to have dev support by the way
silent horizon
Let me look back at the object IDs you sent over earlier to check something
light hare
last week I was doing a $0 capture to confirm the payment method and store it, which works, but is a bad experience if you're google or apple pay, probably a bad experience with cards doing an auth flow showing the amount too
silent horizon
Is there a reason you're not using Setup Intents to do this instead?
light hare
That's what I was doing, but leads to an apple and google pay prompt for $0 on our checkout screen that also shows the real amount being charged
using the pay intent with setup future usage gets me the amount right
but also have to do the first capture using o_b_o it looks like
silent horizon
Wait - let's back up for a minute. Can you confirm everything below:
- You want the Google/Apple Pay prompt to show the real amount that will be charged in the future
- Ideally, you DO NOT want to capture the original Payment Intent that is created on the platform account
- These are Standard accounts, correct? I assume you want to be making direct charges on the Connect account?
light hare
yeah that's correct
well, I'm pretttty sure on the "standard account" bit, not sure the nomenclature
we don't onboard them, you do, that sounds standard to me
they just go through the oauth connect flow
silent horizon
Yup that's standard
And how are you integrating with google/apple pay? Through the Payment Request button?
silent horizon
One more question - is there a specific reason you need cloning? Is there a reason you can't just create the Payment Method on the connect account to start with?
light hare
Marketplace, ~3000 sellers, want the buyers to be able to come back and checkout near-1 click on a new seller.
secondary: governance
silent horizon
Gotcha - so your requirement of wanting the Google/Apple Pay prompt to be able to show the real amount that will be charged in the future is not one that is well supported by the Payment Element yet. With the previous offering (the Payment Request button) you could specify an amount and that it was pending.
Is it a hard requirement that you display this upcoming amount? Ideally you would use a Setup Intent to create + setup the Payment Method on the platform account and the Payment Intent would ONLY be created on the connected account
light hare
yeah.. I'd prefer that cause I've already built and tested it that way 🙂 But it's not a good buyer experience, even if we pre-message it on our site, it's going to blow up support
I can capture it via the confirm on an intent, I just have to rework more of the backend to play nice
So, feature request I guess
I've gotta land this in a day or two, gunna see where I can get with the o_b_o on initial
silent horizon
In general I really wouldn't recommend this - you're going to run into all confusion down the line if you mix up your fund flows like this
light hare
Well, next year I hope to take more control over fund flow, potentially making us merchant of record as well. I could maybe just do payment request button now I suppose
junior merlin
@light hare hello! i'm catching up here, I'd highly recommend following karbi's suggestions but let me know if you have any unanswered questions
silent horizon
I need to head out, but just want to leave one last thing - I do think the Payment Request button will give you more flexibility here if you can't budge on your requirements. While the Payment Element is awesome, it is rather new and doesn't have all the specific features that would make it work for your use case