#rdd0u
1 messages · Page 1 of 1 (latest)
did you confirm the PaymentIntent?
sounds like maybe you just created a PaymentIntent but didn't actually process any payment with an end-customer with it(confirming on the frontend with e.g. PaymentElement and confirmPayment or passing confirm:true and the details of an existing saved payment method on the backend). In which case there's no charge object since no payment was processed.
So no, indeed. Then I am not really clear on the steps needed to initiate a transfer to a connected account. Should I initiate a PayementIntent, then confirm it and then transfer?
for now I'd forget about the transfer and get the payment from the end-customer working
do you already have a payments integration that does that?
Yes
so then you'd have a successful completed PaymentIntent from that flow, and that's the one you can use its latest_charge for the transfer
I have subs on one end from end customers and trying to initiate payments for connected accounts
cool, then for example you pick an Invoice from the subscription that has been paid, and use the charge from that Invoice to fund a Transfer to a connected account.
I really fall in the category of "https://stripe.com/docs/connect/separate-charges-and-transfers#transfer-availability" from this doc
People subscribe to the service, access a marketplace, select a "product" (face to face course), so the transfer =>payout is only done once the course has effectively been attended. Which could happen weeks after a booking.
sounds good
probably what I would do is have the Transfer happen immediately, but delay the payout from the connected account(keep them on manual payouts and don't call the API to process a payout) until the attendance happens
It is a lil' more complicated than that in my case a sub could be worth £10, but I convert that to a credits system. Credits can be saved for x months to get access to a course. So the charge associated with a sub might not cover the transfer, but 3 or 4 of them would. If you know what mean?
then I suppose you'd have to do multiple Transfers, from mutliple source_transactions then.
Do the transfers have to be linked to a charge? Couldn't I simply initiate the transfers once a course occured?
Without PaymentIntent?
they don't have to be, but if they are not, then they require your platform account to have the full amount of the transfer 'sitting' in your available balance.
that is completely possible(you change your platform account to manual payouts so we stop paying out your balance automatically and instead all your incoming funds just accumualte over time, X days after the charge (depending on your account's payout timing)) , it's just generally more complex.
under normal cicumstances(the default situation where your platform accounts is on automatic daily payouts) , calling /v1/transfers never works without source_transaction, since you never accumulate available balance because it is just constantly being paid out.
Nice one. Last question, how would I apply a fee prior to a transfer if I were to link it to a charge from a subscription?
well there wouldn't be an explicit fee (like a Stripe ApplicationFee object) in this flow
you'd just Transfer an amount X out of the Y amount of the subscription payment, where Y-X is the "fee" you are keeping
our API fields/objects like application_fee_amount only work for 1-to-1 payments between a platform and one connected account and where the fee is known and taken at the time of the payment, if you have a use case that is separate-charges-and-transfers you take the fee by reducing the amount of Transfer(https://stripe.com/docs/connect/separate-charges-and-transfers#collecting-fees).
Which makes sense, thanks. Is there an option to customise the line items in the invoice then as it looks like I have a legal requirement to display a seller's fee on the invoices intented to the connected accounts (think ebay raising an invoice for the seller)
maybe add a memo or footer with the legal text needed https://stripe.com/docs/invoicing/customize
the actual line item description comes from the name field on the Product object associated with the Price used, so not really customisable