#Nils Mehlhorn

1 messages · Page 1 of 1 (latest)

void craterBOT
jovial maple
#

Hi there, so you want to create card payment methods from the customers so that that you can create on_session charges later?

cinder ravine
#

Hi Jack, I've got a mixed cart (say, 3 products from Connect Account A and 1 product from Connect Account B) and want to create a destination charge per Connected Account which is paid via credit card.

jovial maple
#

For destination charges, the charges are created on platform and the funds are later transfer from platform to connected accounts

cinder ravine
#

I know, I've got destinatin charges working in production with SEPA bank transfers 🙂

jovial maple
#

So in this case you need to create customers and card payment methods in platform.

cinder ravine
#

Customers are already created upfront. Now I want to keep the checkout as smooth as possible (only have credit card input and authorizatio one). I was thinking that this might be possible via setup intent and then creating two payment intents on the saved credit card.

jovial maple
#

There are many ways to create a payment method for a customer for future use. You can use SetupIntent + PaymentElement, or PaymentIntent + PaymentElement with setup_future_usage set to off_session, or just use Checkout.

cinder ravine
#

So, Checkout is not an option because the experience needs to be whitelabled. Also, our whitelabel checkout basically displays the mixed cart as one order, however, in the background these are separate legal purchases per connected account (incl. separate invoices). But during our whitelabled checkout I want to have the customer input his credit card details only once, however, I'm fearing that it'll trigger multiple authorizations.

jovial maple
#

Hmm, I don't quite understand what you need

cinder ravine
#

I'll try explaining it again, just a moment

#

I've got a mixed cart (3 line items, 2 belong to one merchant/connected account, 1 belongs to another) which the customer is taking into our white-labeled checkout. There's a step for selecting the payment method (up until now, only Stripe bank transfer is possible which doesn't require Stripe.js). Now, when the customer selects credit card as payment method, I want to make sure that they only have to input and authorize their payment details once but I need to create a payment intent (destination charge) per merchant (in reality maybe even more than that because some line items may require a hold/deposit until the customer has sent back their old product). Is that possible or do I need to move separate charge and transfers?

jovial maple
#

If multiple connected accounts are involved in one payment, I don't think the destination charge flow would work, you need to use separate charges and transfers.

cinder ravine
#

That's why I'm thinking of accepting multiple payments in one session. Would that work somehow?

#

Preferably, without too much hassle for the customer

jovial maple
cinder ravine
#

We're currently using multiple payments because with bank transfers this would provide multiple bank transfer details which is something that works well when printing those details on invoices. Having multiple payments when paying via bank transfer and only one payment when the customer uses credit card considerably complicates our system - that's why I'm evaluating how we'd prevent that :/

jovial maple
cinder ravine
#

Are there some kind of limitations to off_session charges? E.g. we might be dealing with 4 to 5 figure payments.

jovial maple
#

However, please note that the card issuer decides when a authentication (i.e., 3DS is needed), so your integration need to handle the situation when PaymentInent's status becomes requires_action, and you need to bring your customer back to your website and use stripe.confirmPayment to trigger the 3DS flow

cinder ravine
#

Okay, ideally, the customer would still be in my checkout session while I'm creating the "off_session" charges.

#

Because I'd create them directly after the setup intent is done once the users confirms their order

#

But honestly, I'm still suspecting that might trigger multiple authorization steps during checkout (or at least later on) which seems cumbersome but unpreventable

heady quarry
#

👋 taking over for my colleague. Let me catch up.

heady quarry
cinder ravine
#

Alright, but imagine I handle this via payment intent with setup_future_usage. The whole order costs 1000€, the part belonging to one merchant 800€, 200€ for the other merchant. It's weird to have a payment intent for 800€ with setup_future_use and afterwards another for 200€. Therefore I thought of having the setup intent and directly creating two payment intents based off of that once the user confirms the order at the end of my whitelabled checkout session.

heady quarry
#

no need to do that

#

as a platform you can collect the 1000$ with one Payment Intent and then transfer each merchant's cut

cinder ravine
#

I know, I was hoping there's another option though. Currently our system is designed for destination charges. So handling both cases is additional complexity...

heady quarry
#

with on_behalf_of?

cinder ravine
#

Without on_behalf_of. But having multiple destination charges allows us to have bank transfer details for individual invoices per merchant.

#

We're a B2B platform based in Germany where companies love paying stuff via bank transfer based on invoices with one payment per invoice for accounting purposes.

heady quarry
#

I see

cinder ravine
#

Altering the 1-to-1 connection for invoices and payments based on payment method is complex

heady quarry
#

I think it's more based on whether it's a single merchant or multiple

cinder ravine
#

Partially. But, we're sometimes also issueing multiple invoices per merchant because some products require a deposit until the customer has sent back their old product.

#

Disclosure: we're not using Stripe invoices, but I'm mentioning this from a contractual perspective between merchant and customer.

heady quarry
#

in that case you don't really care about the payment being tied to an invoice

cinder ravine
#

Companies love associating payments with invoices in their accounting

heady quarry
#

again sorry I'm not really familiar with the market there and how they deal with stuff

#

I see what you mean know

cinder ravine
#

No worries, thanks for sticking with me

heady quarry
#

so 1 payment = 1 invoice (same amount)

cinder ravine
#

Yes

#

When a customer buys a product that requires a deposit, we'll issue two payments: one for the purchase (say 800€) and another for the deposit (say 100€). Each payment gets and invoice. Once the customer sends in their old product, we credit the deposit invoice and refund the corresponding payment.

#

In the end, that should all be possible if we can perform multiple charges within one session. Everything already works with bank transfers.

heady quarry
#

why not have multiple line_items on the same invoice

cinder ravine
#

It's easier to credit a whole invoice than to only credit individual line items.

heady quarry
#

like if you were using Stripe Invoices you would be able to have an invoice with 2 line items, a total and can be paid in 1 transaction

heady quarry
cinder ravine
#

Also, doesn't solve the underlying issue: we need multiple payments either way, one per merchant

#

We can't use Stripe invoices because our merchants need to issue their own invoices, sadly..

heady quarry
#

yeah we're kind of stuck in a loop here 😅

cinder ravine
#

yeah, guess I'll have to use separate charge an transfer then

heady quarry
#

then you don't have a choice but to create 2 Payment Intents

#

these are basically your 2 options

cinder ravine
#

yeah, but multiple authorizations are probably a conversion killer

heady quarry
#

authorizations are only needed if the issuing bank deems them necessary

#

if you're doing an off_sesssion payment

cinder ravine
#

Can I do off_session: false somehow? Because the customer will still be in my checkout session at that point

#

Don't know if that helps though

heady quarry
#

I'm not sure how the issuing bank will interpret that. yes off_session: false means that the customer is on_session but the repercussions of that can differ from an issuing bank to another

cinder ravine
#

Okay, I'll think about which route we'll take, thanks for your help!

heady quarry
#

I'm sorry I wasn't that much of a help after all