#muni - pay later

1 messages ยท Page 1 of 1 (latest)

fading condor
#

The difference is whether you are collecting a payment right now or not. If you were only setting up a card for later, you'd use setup mode and create the payments later as needed.

#

If you were collecting a payment now and wanted to save the payment details for later, you'd use payment mode and setup_future_usage to preapre the payment method for those additional future payments.

violet orchid
#

Ok, I think I get it.

#

I want to collect payment info to charge that card (or not) a few days later. So I'd set up a setup session.

#

I can create a payment intent and send it through the setup_intent field to the session, right?

#

And then charge that payment intent?

fading condor
#

If you mean you want to get a full authorization to charge for an exact amount, you might mean you want manual capture instead

violet orchid
#

Yeah that's what I want. Can I create that paymentintent, and then create a session (for the user to confirm the amount and input credit card details) and feed that paymentintent to that session?

fading condor
#

No, you're create the session with the payment detials and Checkout creates the payment intent for you, as well as collecting the payment details from the customer.

#

If you're collecting the payment detials in your own custom integration, there is no need to use Checkout. You can use manual capture with a custom integration, too.

violet orchid
#

I think it's the first solution. So how do I get the paymentIntent ID after the user returns from checkout?

fading condor
violet orchid
#

Alright, one last question, when's the right time to indicate the account that will receive the payment?

fading condor
#

What do you mean exactly? Can you explain mroe about what you're trying to do?

violet orchid
#

Yeah, so essentially we're accepting payments on behalf of our partners. So we have them use stripe connect to sync with Stripe. We get them through onboarding, they register their company details with stripe connect and we hold on to an account id (acct_xxxxxx)

#

So when we accept payments, we need to pass on an account id to tell stripe where to send that payment to.

fading condor
#

Ah gotcha, thanks

#

You'd do that in the payment_intent_data also, when creating the session

#

Assuming you're using destination charges

#

What charge flow are you using?

#

(Direct charges would be a different pattern)

violet orchid
#

I wouldn't use the payment_intent_data object since I'm creating a "setup" session, right? The way we need to do stuff means there may be two steps to charging a customer, 1 - collect payment information (and authorization to pay) 2 - confirming the payment intent (collecting the money)

#

As far as "charge flows" I'm unsure about what you mean

fading condor
#

There are a few different ways to create payments involving connected accounts

#

If you're setting up without payment, you'd indicate the connect account transfer/ownership when creating the payment later. The details really depend on the cahrge pattern you're using.

violet orchid
#

Destination charges, I think. We want the money to go directly to the partner, but a couple of days lag in that (to allow refunds, disputes, etc) would be nice.

#

We've had a few charges going through the platform already, but I've never created a "Charge" object, or "Payment" object either.

#

We usually create payment intents and then confirm them.

fading condor
#

And you're already doing that for connected accounts?

#

If so, can you share an example that my colleague @native harbor can peek at to confirm the charge flow you're using, then you can use the same going forward

native harbor
#

Hi ๐Ÿ‘‹ I'm stepping in here

violet orchid
#

Hi Snufkin

native harbor
#

Okay so you've reviewed the charge types and can confirm that Destination Charges are what you are looking for/using?

violet orchid
#

That was our process, I'm doing a few corrections because I was creating a session (mistakenly in payment mode, which caused an immediate charge) and then I was creating a paymentintent out of the blue.

#

I need to see what you mean with Destination Charges

#

I'm finding out I know a lot less of the Stripe API than I thought, sorry about that!

native harbor
#

No worries, it's my job to know this stuff and I still need to re-read the docs regularly.

violet orchid
#

lol and it's not like it's a bad API, far from it.

#

So would it help if I tell you exactly what we want to do?

native harbor
#

Sure

violet orchid
#

So we are a marketplace, that will sell virtual events, charge the people attending and direct those funds to the people providing the materials for the events.
We need the funds to be transferred directly to the producers of those materials. We also want people to input their credit card /payment information when they register for an event, and for that to only be charged when the event is confirmed by the person organizing it.

#

So to start, we have the producers register with a stripe connect account. We do this by calling /accounts with type express (to create an express account) and then calling /account_links to get a link to the onboarding flow.

#

Then we save that express account number (acct_xxxxx) and use that as the destination for funds.

#

does that make sense so far?

native harbor
#

Yup, destination charges still makes sense

violet orchid
#

Ok so, our purchasing flow means a lot of stuff can happen:

  • Guests may pay for the event, or for the event plus shipping
  • All guests may pay their part, or it may be payed by a single individual
    shipping I handle by simply adding another line_item when creating the session
    The split pay though means two things:
    Either it's payed for by a single person, and in that case when they confirm the event, I (now know that I need to) create a session with mode=payment and that'll mean that the card gets charged immediately.
    Or in the case when everyone's paying their own way, I need some ability to synchronously collect card information, and then asynchronously (off session) charge those cards.
#

The way we've been doing this is by getting a payment intent, and then calling confirm payment intent on the API.

native harbor
#

Okay so with CHeckout mode=payment you can include the transfer data for destination charges. For in mode=setup you can still use on_behalf_of to create the Payment Method on the connected account.

violet orchid
#

alright! That makes sense.

#

Will there be any difference in the processing of these charges other than the actual charging be done in different times?

native harbor
#

Once you use a setup intent to create the payment method on the connected account, you will need to process a payment intent using the payment method ID rather than collect card info all over again.

violet orchid
#

Alright, that's what I was thinking.

#

If in the future I want to split that charge into different payments (collect from one payment method and pay to two different companies) is there a way to do that?

native harbor
#

That is more of a Separate Charge and Transfers charge flow. The initial charge exists on the platform and you transfer portions to other connected accounts

violet orchid
#

Ok, how would I set that up?

#

Thanks so much for your help, you guys are great!

native harbor
#

๐Ÿ‘ Happy to help ๐Ÿ™‚