#dschuett

1 messages ยท Page 1 of 1 (latest)

mild palmBOT
fossil moss
#

Hello

light nebula
#

Thanks we are trying to avoid the Setup Intent.

#

Because they come to our platform to pay an invoice. And we want to ask them in that flow if they want to save it for future usage.

#

And we don't want them to have to reenter the information after the payment.

fossil moss
#

They are paying an invoice on your platform or one of your Connected Accounts?

light nebula
#

On our platform but charged to the connected account.

fossil moss
#

Hmm not sure what that means exactly. Does the Invoice exist on your platform and then you are transferring funds?

light nebula
#

The user pays an internal invoice on our platform. They fill out the credit card data and we initiate the payment using a Payment Intent on behalf of the connected account. So if we use the 'on_session' or 'off_session' it will attach it to the customer on the connected account.

#

We have a customer setup for each user on our platform account and would like to collect all of the stored payment methods there instead of on the connected account's customer.

mint willow
#

Hi there ๐Ÿ‘‹ taking over

Give me a few minutes to get caught up.

light nebula
#

Because they might come back and pay a different internal invoice for a different connected account.

#

ok great thanks

mint willow
#

So if I understand correctly: you're currently creating Customer objects on the Connect account, but you're creating Invoices on the Platform's account. And you want to know if you can use the Customer's Payment Methods (which were created on the Connect account) for Invoices that were created on the Platform account.

Is that correct?

light nebula
#

no we don't use Stripe invoices at all

#

just Payment Intents

#

and I need to attach the payment method used for a connected account payment intent on the platform customer instead of the connect account customer

mint willow
#

I don't think this is possible. For this flow you should have created the Customers and their corresponding Payment Methods on the Platform's account. Right now, if you want to use their Payment Methods, then you would have to create the Payment Intent on behalf of the Connect account and then send a separate transfer to the Platform via an Application Fee.

Happy to talk through that some more if you have questions.

light nebula
#

We are creating the Payment Intent on behalf of the connected account.

#

we can't create the payment methods on the platform account because the initial payment will always be to a connected account

#

and we wouldn't expect anyone to set up payment methods before the first payment

mint willow
#

Wait, so are Customer objects being created before payment in this case? I think there might be a fundamental misunderstanding here

light nebula
#

Is there a way to attach a payment method to a customer after the payment is complete without setting the setup_future_usage first?

mint willow
#

Is there a way to attach a payment method to a customer after the payment is complete without setting the setup_future_usage first?
Yes, though it's not recommended. See the description for the Payment Method Attach API: https://stripe.com/docs/api/payment_methods/attach

light nebula
#

ok so I should be able to use this method to attach the stored payment method of the connected account to the platform account?

#

or will it loos the authorization (setup_future_usage) in the process?

mint willow
#

ok so I should be able to use this method to attach the stored payment method of the connected account to the platform account?
I don't understand this terminology. You cannot "attach a payment method of the connected account to the platform account". Payment Methods are used with Customer objects. Those Customer objects either live under either the connected account or the platform account.

#

Connect accounts do not have Payment Methods.

light nebula
#

connected account customer -> platform account customer

#

my bad I was talking about customer objects

#

so if I attach them to the platform account customer and they authorized off_session payments will I be able to use them still after attaching them?

mint willow
#

so if I attach them to the platform account customer and they authorized off_session payments will I be able to use them still after attaching them?
Just to make sure nothing is being miscommunicated here. You cannot use Customers or Payment Methods from connected accounts to perform actions on resources in the Platform account. So to answer your question: if you create a Payment Method on the Platform account and attach it to a Customer that was created on the Platform account, you can authorize the Payment Method for off-session payments and use them later without your Customer being present in the payment flow.

light nebula
#

so you are saying there is no way to get the payment method from the connected account customer to the platform account customer?

mint willow
#

Correct

light nebula
#

ok is there a way for me request support for this? Because this feels like a pretty normal use case to me.

#

this article is even talking about using them across connected accounts.

#

So I don't understand how it is not possible to actually store it on the platform account customer when initiating a payment.

#

Most checkout flows I've seen don't make you store the payment information before even attempting the payment.

mint willow
#

The cloning of customers happens when you create Customer objects on the platform account. Most of the time, when a Connect Platform knows they'll need to be able to interact with Customers on both the connected account and the Platform, they build their integration such that Customers are initially created on the Platform.

That being said, I can include feedback to the product team for you so that this is on their radar

light nebula
#

We create the customer on the platform account but I can't charge that customer because we need to use the connected account's customer for the charge.

mint willow
#

I've made sure to include that feedback to the product team.

Do you have any more questions for me?

light nebula
#

thank you

#

Is there maybe a way to start a SetupIntent using the paymentMethod of a completed payment?

#

So they at least wouldn't have to reenter the payment details?

#

also are the examples of what the off_session prompt will look like for the payer? And would they be able to not grant off_session but still allow the payment or can they only decline everything?

mint willow
#

Is there maybe a way to start a SetupIntent using the paymentMethod of a completed payment?
So they at least wouldn't have to reenter the payment details?
If the connected account has a Customer and a Payment Method already, then you can use that Customer and Payment method when creating the Setup Intent:

Customer --> https://stripe.com/docs/api/setup_intents/create#create_setup_intent-payment_method
Payment Method --> https://stripe.com/docs/api/setup_intents/create#create_setup_intent-customer

light nebula
#

I don't understand what the point would be of creating a SetupIntent if the payment method is already attached to the customer?

#

The payment method is attached to the payment intent in my example.

woven marlin
#

Hi ๐Ÿ‘‹

There's a lot of back and forth in this thread. What is it you are trying to achieve?

#

Catching up here ๐Ÿค”

light nebula
#

I need to move payment information from a connected accounts customer to the platform accounts customer.

#

Ideally I wouldn't even attach it to the connected accounts customer in the first place.

#

But we collect the payment information via Payment Intent which is using the connected account.

woven marlin
#

In that case the Connected Account owns the information

#

As @fossil moss explained earlier

light nebula
#

Yes I understand. I was trying to find a workaround since this won't work for our use case.

woven marlin
#

Which is why it was suggested you create the Payment Method initially on the Platform account using a Setup Intent and then clone it to Connected Accounts as needed

light nebula
#

But this will make the user authenticate/authorize twice in case of 3d secure, won't it?

#

And would most likely not handle Apple Pay/Google Pay/Giropay etc.

woven marlin
#

Setup Intents work with Apple/Google Pay and 3DS authentication.

light nebula
#

I understand that. But the flow would be:

  1. Entering the card details.
  2. They click the payment button
  3. We initiate the setup intent which they have to authorize.
  4. We initiate the payment intent that they have to authorize again.

Unless we initiate an off_session payment for step 4 which wouldn't be a proper apple pay payment since we charge the card directly?