#mike_docs

1 messages · Page 1 of 1 (latest)

steep coralBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1383068623043690578

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

harsh lodge
#

hi there!

#

yes! how are you acceping payments? Checkout Session, Payment Element, something else?

steep coralBOT
earnest finch
#

we create payment_intents with setup_intents before and we use payment elements

harsh lodge
#

then set application_fee when you create the PaymentIntent, and it will apply regardless of the payment method used.

earnest finch
#

good to know. can you redirect me to the right docs source how we can allow our sellers to create bank account (with iban, swift, etc.) similar to how they create card payment_method?

serene ibex
#

how we can allow our sellers to create bank account (with iban, swift, etc.) similar to how they create card payment_method
Can you say a bit more about this so i can help point in the right direction?

#

(stepping in for soma who needs to step away)

earnest finch
#

Well we have UI to create card (setupIntent) and store the result in our database so the users can choose among their cards created. Now we would like the connected_account to create same/similar way the bank account on stripe and we receive payment_method_id and store the bank details in our database as well. Next we can display bank details to the customer if they decide to buy the product via bank transfer. does it make sense?

serene ibex
#

Part of what you're describing are actually about two different payment methods: bank debits and bank transfers. Are you trying to collect bank account info from customers to debit them from your side, or give customer bank account info for them to transfer to, or both?

#

Both is totally fine, but i want to clarify what you're asking since these are pretty different from one another

earnest finch
#

🤔 maybe we would need dig deeper in the docs...? the idea was about creating payment_intent (after the order was created) with allowed payment methods: card only or card+bank. In case the bank is allowed to be used for this purchase (not all orders are allowed to do so) there should be opened new page with bank details for the customer so they know where to send the money to (I suppose these are bank account created in stripe domain). Once the payment comes to the stripe bank account (from the customer bank account via wire transfer) we should receive webhook to release the order. To give more context: we use STANDARD connected accounts and direct charges.

serene ibex
#

This requires you to make some integration changes to provide required values for initializing that bank account & payment, as explained in the doc (same as the one you linked)

#

Notably, with bank transfers, there is no payment method object. Instead there is a cash balance on the customer for reconciling against payments.

earnest finch
#

I am a little bit confused by the sentence: "The first time you accept a bank transfer payment from a customer, Stripe generates a virtual bank account for them, which you can then share with them directly."

I expected the virtual bank account will be created not for the customer but for the vendor... 🤔

serene ibex
#

This is in contrast with bank debits which do create a payment method object, and work more or less out of the box once you enable bank debit payment methods in your settings.

serene ibex
#

Who is the "vendor" in your model?

#

the connected account?

earnest finch
#

we are b2b and b2c marketplace platform. Customer is customer 🙂 vendor = connected_account. the platform currently stores the customers' payment_methods and clone them for every purchase of the customer from the vendor.

#

we (the platform) should receive our part (application_fee) from every transaction regardless it is via card or bank transfer - that is the whole idea

serene ibex
#

So for bank transfers, a virtual bank account number (VBAN) is created per customer, per account, so that funds are correctly attributable to that specific customer & account.

#

(There's also a factor of the country you pick if in the EU, but for this clarification we can mostly ignore that)

earnest finch
#

we want to be world-wide one day but we are going to start with EU (vendors).

serene ibex
#

When you create a payment with bank transfers for a given customer on a given connected account, we look for an existing VBAN for that combination or create a new one. Then when the customer transfers funds to that VBAN we can isolate it for them on that specific account.

earnest finch
#

so "when" the VBAN is created? I thought vendor will create their account (now it looks like it's not that way) and publish the bank info (iban, swift) so the customers can pay to it... 🤷‍♂️

serene ibex
#

If you're using direct charges, the VBANs for the same real-world customer (a single person) will be different for each of your connected accounts, so its important to be aware of this if your customer pay multiple vendors, to ensure they send funds to the correct VBAN

#

Its created when you first create a payment intent or invoice for the customer

earnest finch
serene ibex
#

Or you can explicitly pull the "funding instructions" for a customer, even before creating any payments

#

So you can give customers bank details to use before you have anything to charge them for, if needed

#

So the customer can transfer funds, which accrue in their cash balance, which you can then reconcile against payments you create

earnest finch
#

how long will it last? forever?

#

or is it discarded after successful payment like virtual cards in Revolut?

serene ibex
#

It is persisted / re-used, and yes unique/specific to the connected account x customer (and country, as I mentioned)

#

I'm not aware of any kind of limit on account life or disabling/recycling etc.

#

As far as i know, it is for that customer forever.

earnest finch
#

with cards (setup_intent stored in our "platfrom" account) we have to clone them to every payment_intent. is it same with VBANs? we create them in our platform account and clone them for every payment_intent?

serene ibex
#

No, not the same for VBAN -- since there is no customer information collected there is nothing to share (and there is no payment method object to share anyways).

#

You can just initialize the VBANs for connected account customers as needed for payments

#

then tell the customer to use those details (funding instructions) for that vendor/connected account

earnest finch
#

on which object will the VBAN stored and in which account platform=ours or connected?

serene ibex
#

Confirmed VBANs don't expire and aren't re-used

earnest finch
#

how can we access the information anytime the customer asks for the details for a specific payment_intent (even later)?

serene ibex
#

if you have a platform concept of a customer, you'll want to keep track of the mapping from platform to each related connected accont customer, in order to show them the right VBAN per connected account

earnest finch
#

we store the Customers only in our (platform) account and for every purchase we clone the card (with customer_id in it) and so in the connected_account there are transactions with a Guest customer. To my understanding the customers in the connected_accounts are not created the same way as they are in the platform. They are created via those transactions. Can you please say it simply (we'll read docs for more details of course) what will be the api flow?

serene ibex
#

So you don't currently create customer objects on the connected accounts and attach the shared card there to persist it? You clone again for each payment and pay without a customer on the connected account?

#

Assuming I understood correctly, you will need to adjust things a bit for bank transfers, since they do require an actual customer object.

#

To my understanding the customers in the connected_accounts are not created the same way as they are in the platform.
I'm not sure what you mean by "the same way" here, can you elaborate?

earnest finch
serene ibex
#

That's perfectly fine for cards, but won't work for what you've described for bank transfers. You'll need the actual customer object to be created on each connected account in order to get the VBAN

#

so if you have some customer A on your platform, and connected accounts C1 and C2, you need to create customers A1 and A2 on each connected account, respectively

earnest finch
#

so we cannot use the guest customer for that?

serene ibex
#

then keep track of your link from A to A1 and A2

serene ibex
#

then you'd have VBAN1 and VBAN2, both for customer A, but tied to each connected account/vendor via customers A1 and A2

earnest finch
#

ok, so we can keep the card implementation as it is and for the VBANs we need to clone (create/copy whatever) the customer to each connected_account before creating the payment_intent. am I correct?

serene ibex
#

When customer A sends money to VBAN1 it lands in the cash balance for A1 on C1, if they send money to VBAN2 is lands in the cash balance for A2 on C2, etc

earnest finch
serene ibex
earnest finch
# serene ibex Yes, you'll need to replicate at least some customer info, like email & name, to...

that's doable but I see one issue here. If you say we have to clone the customer to the connected_account to have the VBAN we cannot allow card or bank for the payment_intent as we clone the payment_method with customer_id (stored in our platfrom account). would it work? if the customer_id on the payment_intent (for the VBAN) will be different from the customer_id used in the cloned payment_method for the card? Will not happen the error we've met before: this payment_method has been associated with another customer...?

serene ibex
#

If you want you can also attach your cloned cards to the cloned customer object, but thats entirely optional

#

You can keep doing your card payments as you have them, the payments intents wouldn't have any customer at all

#

but yes the bank transfer payments will all have a customer id, they have to in order to get the VBAN

earnest finch
serene ibex
#

Will not happen the error we've met before: this payment_method has been associated with another customer...?
This doesn't apply to bank transfers, since there is no payment method, and the VBANs are inherently already tied to a specific customer

earnest finch
#

even after 3 years with stripe we often feel lost 🤯

serene ibex
steep coralBOT
earnest finch
#

does stripe support provide some implementation review (even as paid service) before launching the product? we are quite uncertain of the implementation we had to changed it few times already due to misunderstanding of documentation or not precise information provided. The docs are huge and even we implement just a part of your features it is sometimes like a Sisyphus's work

hard fulcrum
#

Hi, taking over as my teammate needs to step away. Let me catch up.

earnest finch
earnest finch
hard fulcrum
earnest finch
#

great, we will definitely do that. for now. can you suggest the best way how to implement VBAN along with existing implementation of payment_method cloning? We don't want to change implementation of this part due to limitations of VBAN.

hard fulcrum
#

You can continue to use the existing VBAN for those existing customers. Then, you'd want to collect new details to create a payment method to clone

earnest finch
hard fulcrum
#

I'm sorry to hear that. If you need professional services, you will need to go through that link.

#

Otherwise, we are here if you are a developer and working on your integration directly with Stripe.

earnest finch
hard fulcrum
#

Great, we're here to unblock you while you work on your integration if you do not choose to go through the professional services and intend to code on your own.

earnest finch
# hard fulcrum You can continue to use the existing VBAN for those existing customers. Then, yo...

we are going around this issue here. I try to summarize again what we have and how I understand we should do the VBAN. please confirm or suggest something else:

  1. card - we create payment_method in our (platform) account and reuse (clone) it for every purchase (customer purchased from us as a platform or from the 3rd party provider = connected_account). The reason is we want to simplify UX - the customer would create the payment_method only once and they can manage the cards in our platform environment. When we clone the payment_method for the payment_intent we always include the customer_id to avoid misusing payment_method for two different customers. This was suggested by this support here and this works as we wanted and expected. To my understanding we cannot clone the customer itself and assign it to the cloned the payment method because this would produce the error: this card belongs to another customer.

  2. vban - as I understand correctly we MUST create a customer in connect_account to be able to create unique vban for the customer+vendor. Considering existing implementation there can (not have to) be the customer created already via the cloned method. It marked as Guest which we are not sure what it means or any consequences it can have. 🤷‍♂️ if we need to create the customer to assign VBAN to them there could be duplicity (one from the card cloning and second created directly). am I correct?

I need some way out from this...

hard fulcrum
#

To clone card payment methods, here is how the logic would be and order of operations:

1/ Create the customer on the Platform Account
2/ Create the Payment Method on the Platform Account using SetupIntents by passing the customer id on the SetupIntents
3/ Create a Payment Method (via /v1/payment_methods endpoint) using the Stripe Account Header and by passing the above object ids both the customer id and the payment method id. It creates a new payment method id on the Connected Account
4/ Create a charge using that payment method from 4.

This way, you won't get that error you noticed. We document part of the flow here: https://docs.stripe.com/connect/direct-charges-multiple-accounts#clone-and-create-direct-charges

#

As for VBAN, let me confirm on my end

#

I was under the impression that you could not clone Bank Transfers

#

For VBAN - yes, you need to create a customer on the Connencted Account but you cannot cloned like it exaplins above for Card payment methods. You will need to create a customer object for VBAN for work. Yes, it will be dupicate as each customer will have their own VBAN. You will need to come up with a way to track them on your end to link them

earnest finch
#

ok, thank you for now. I am afraid I will definitely come back with this issue in the near future... 😉