#mijelz-cancel-payment

1 messages · Page 1 of 1 (latest)

dry osprey
#

why not have your db re-do the operation?

craggy pecan
#

Idk for example, the DB went offline or something of the sort, networking error, etc. Ideally I would like to make a flow like:
--- Post data to DB
--- Charge Card
--- If card charge fails, undo db change

#

But I don't wanna be in a state where like, we added orders to a customer on our DB side, even though the charge failed. To clarify, we sell online courses automatically so fulfillment is done that way

#

its all digital fulfillment

dry osprey
#

so you've flipped your flow, earlier you said you create Charge, then write to your db first, now you've said the opposite

but really the right thing to do is to first make a charge, wait for a successful response and if so, write to your db, if you get a decline, then you don't write a new "order" to your db

craggy pecan
#

Yes sorry 😅 Just trying to figure out the best way to go about this

dry osprey
#

and you handle retries to your own db if it is down, for instance, you shouldn't refund charges just cause your refund failed, as you can always fetch them from the API and know charge_1 did succeed

craggy pecan
#

Gotcha, can I add extra metadata to a purchase that gets sent to Stripe so it can send back it over when I confirm with charge_1 success

dry osprey
#

yes

#

assuming you're creating a /v1/charges but works the same with /v1/payment_intents