#jaybabu_partial-payments-hold

1 messages ¡ Page 1 of 1 (latest)

stiff locustBOT
#

👋 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/1481684618678636584

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

native saddle
#

creating a charge directly via the api is not recommended

near light
#

Yes creating Charges directly is deprecated

#

What events you listen to is highly dependent on what data your integration needs

native saddle
#

yes, asking about the webhook. just wanted to clarify my original message

#

yes, i see a path forward with charge.succeeded. i just wanted to know if that webhook or any field on that webhook should not be used

near light
#

I'm still not clear on what your actual question is. We don't have specific best practices.

#

i just wanted to know if that webhook or any field on that webhook should not be used

I don't know what you mean by that

native saddle
#

currently we create a customer via accounts v2. we also save this in our own db

then in a card present payment, we pass in setup_future_usage + acct_id. we then want to save that data in our own db as well. the generated card to show this customer has this attached to their customer. we add metadata on the pi that we need to link back to the customer in our db

the pi.succeeded doesn't have any reference to the generated pm. the pm.attached doesn't have metadata filled in nor does it have a reference to the original pi it was created/attached from

#

the charge.succeeded has all of that information. is it safe to use charge.succeeded for new use cases? is it deprecated as well similar to the api? are there certain things to avoid within that object?

#

it links to the generated card. it links back to the pi. it also has the metadata object filled in

near light
#

Ah I see the confusion now. The deprecate of using the Charge API has no impact on the validity of the data in the charge.succeeded webhook event

#

We are not deprecating the Charge object entirely, we are just moving this to an internal primitive object. Each Payment Intent will create one or more Charges as part of it's lifecycle

#

But, if you want to get all the data in one payload, then I recommend listening for the payment_intent.succeeded event, check if the PMT is card_present, and if so retrieve the specific Payment Intent object with the latest_charge expanded. That way you get your metadata and the details of the generated card PM

native saddle
#

okay that makes sense. and all of the fields on that object can be used safely? there is no deprecation on it?

#

we can't make another api call. that is a constraint

near light
#

Correct, all that data is still accurate

#

Gotcha, in that case you may need to listen to multiple event types to get all the data you are looking for

native saddle
#

we save each event's data and save it in our own db

near light
#

Got it, that makes sense

#

I set up something like that in my first test integration

native saddle
#

but you recommend listening to pi succeeded then getting the charge instead of listening to charge succeeded?

#

oh haha that's funny

near light
#

Well actually metadata from Payment Intents are copied to Charges. It's one of the exceptions we call out here https://docs.stripe.com/metadata#exceptions

And the Charge object will include the customer ID. So I think listening to charge.succeeded makes sense

native saddle
#

okay, so even though it is an exception, it is fine to rely on that?

near light
#

Yes. This isn't something we are going to change.

#

When I say it's an exception, I mean it's part of our core API design. We don't copy metadata for most Stripe objects but we do when it comes to Payment Intents & Charges

native saddle
#

ahh i see makes sense

#

since this indirectly came up. pi has latest charge id. does that mean it can have multiple charges? i didn't see stripe support multiple partial payments to one payment intent. that would solve a lot of burden that we currently have. we currently create multiple payment intents in one transaction then auth each one since the client uses separate cards and at the end capture each one. then have to handle potential rollback (refund) issues

near light
#

A payment intent can have a single successful charge. But we sometimes need to create multiple charges in situations where one fails.

native saddle
#

Okay, I see. So essentially partial payments is not a thing

near light
#

Not for Payment Intents. We do enable it for Invoices

native saddle
#

actually iirc, invoices is the correct construct to use for that with the newer version?

near light
#

Yeah we added the ability to link multiple Payment Intents to a single Invoice

native saddle
#

i don't see this after a quick search. didn't dig to deep. how does stripe charge multiple cards on an invoice? usually, a customer is like i have $5 to spend on card 1. then $3 to spend on card 2. the total is $8. we charge card 1, that succeeds. then we attempt to charge card 2, it fails due to not even balance. customer says i can't buy it, so we want to cancel it. how can we have the $5 available for them to use immediately?

near light
#

I'm not sure I follow.

What do you mean by "having the $5 available"?

native saddle
#

only some cards support reversal. assuming they don't, it takes multiple days for the funds to get back on a successful payment

near light
#

You mean returning the funds to the customer?

native saddle
#

for card 1, they went to the terminal and put down their card. we then succeeded the payment intent i am assuming to do the first partial payment

#

on the invoice

#

they then canceled the order let's say, saying i don't want this anymore. we have refund their money. how can that part be instant given that the invoice wasn't fully paid

near light
#

It goes through the standard refund process

#

It doesn't matter that the Invoice wasn't fully paid

#

The Payment Intent was completed

#

If the payment qualifies for a reversal, then Stripe will attempt that. Otherwise it will use standard card refunds

native saddle
#

yes, asking if there is a way to avoid that. like can i create an invoice, auth a partial payment of $5, attach to invoice, then auth a partial payment of $3, attach to invoice. then have stripe capture and complete all of them?

#

if 1 fails, then refund the whole thing

#

basically want all or nothing on the invoice

near light
#

So essentially you want to use a Separate Auth & Capture flow for each Payment Intent you are linking to the Invoice.

native saddle
#

yes, but it should capture all or capture none if there is an issue with any of them

near light
#

What you could do is this

  • generate one Invoice, let's say for $20
  • follow this guide for multiple Payment Intents, let's say $10, $5,, and $5
  • Capture or release the Intents based on the customer
  • If you capture all the funds, then you link the Payment Intents to the Invoice <= when the linked Payment Intents total the amount of the Invoice, it automatcally transitions to status: "paid"
#

Does that make sense?

#

It would be pretty easy to code a simulation script to test this flow

native saddle
#

okay makes sense. this is pretty similar to what we have right now except without the invoice part. if you cancel an auth, then the funds go back immediately like the charge never happened. but if you capture 1 and then capture 2 fails (very rare), we have to issue a refund on 1. was wondering if that can be handled by stripe or not

near light
#

Yeah, that's because the funds never left the customer's account. The bank just sets them aside to prevent the customer from spending them

#

And their statements make it look like the money is gone

#

But you are right, Stripe doesn't have a way to automate this process completely. Right now you kind of need to build it out using the steps I outlined.

native saddle
#

yes, the auth part makes sense. we currently have that. was wondering if stripe would handle capturing if the invoice had all payments authed and the total matched

near light
#

Yeah that isn't how the multi-payment part was designed.

#

Because many merchants want to actually collect each separate payment

#

Imagine a home contractor who Invoices a customer for $100K but spreads that out over 10 payments

native saddle
#

the ideal flow would be

  1. create invoice
  2. attach successful auth payment intents like $5 and $3
  3. stripe sees that all the auth payments match the invoice total (or exceed). capture all of them
  4. invoice succeeds

yeah, i guess that is too much opinionation

near light
#

The contractor still wants each $10K payment

native saddle
#

yeah makes sense. i understand the flow

near light
#

But it's a good point

#

That is something we could eventually configure

#

It's kind of the flow with Stripe products. We start with providing the flexibility to build this all yourself. Then our customers try out all the different flows these options enable and we find the common ones and try to automate those

native saddle
#

yeah makes sense. we had to essentially create partial payments with our own concept of invoices since stripe didn't support it 2 years ago otherwise probably would've stuck with this

near light
#

Gotcha. But does what I suggested seem feasible?

stiff locustBOT
#

jaybabu_partial-payments-hold

native saddle
#

yes, it makes sense. i just don't see the benefit of using invoices. we do this portion but surround with our version of invoice

follow this guide for multiple Payment Intents, let's say $10, $5,, and $5,
Capture or release the Intents based on the customer,

#

we create an invoice. charge the payments then attach to the invoice which then gets successful. almost exactly the same

near light
#

Sure. The only reason you'd use the Stripe invoices would be if they offered some additional value to you like making book keeping easier

#

Or Stripe-generated Invoice receipts

native saddle
#

yep makes sense, thank you

#

that should be all for now

#

thanks for all the help