#mijelz-cancel-payment
1 messages · Page 1 of 1 (latest)
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
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
Yes sorry 😅 Just trying to figure out the best way to go about this
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
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
yes
all that is in the API ref https://stripe.com/docs/api/charges/create
assuming you're creating a /v1/charges but works the same with /v1/payment_intents