rlindsey-paymentintent-events

[chrome sparrow]

Charges will not be going away any time soon

Payment Intents are built on top of Charges

[worn solstice]

Ok cool. So no plans to separate them? Sounds like option 1 would be the way to go then for simplicities sake.

[chrome sparrow]

In your case I would simply listen to charge.succeeded` although the other Payment Intent events would be useful to be informed about other actions on the Payment Intet

Yeah, Option 1 would be the most simple way to go

[worn solstice]

Thanks!

In the PaymentIntent flow, are there any concerns with a charge.succeeded event occcuring without a corresponding payment_intent.succeeded?

[chrome sparrow]

No that isn't something that will happen.

[flat vigil]

@worn solstice I would highly recommend starting to listen to payment_intent.succeeded. What you can do is set metadata on your PaymentIntent so that you can detect this on the resulting Charge when you get charge.succeeded

rlindsey-paymentintent-events

[worn solstice]

In my option 2 above I was basically planning to filter out charge.succeeded events which had a PaymentIntent associated.

e.g. I would process all payment_intent.succeeded and all charge.succeeded where the payment_intent field is null.

{
"object": {
"id": "ch_3NJfX9Lab5ZaWGur07kRPBuK",
"object": "charge",
"amount": 2000,
"amount_captured": 2000,
"amount_refunded": 0,
"payment_intent": null
}
}

I would filter out and not process charge.succeeded which looked like this with a payment intent attached

{
"object": {
"id": "ch_3NJfX9Lab5ZaWGur07kRPBuK",
"object": "charge",
"amount": 2000,
"amount_captured": 2000,
"amount_refunded": 0,
"payment_intent": "pi_3NJgMTLpw5ZaWGab0eI1pMJM"
}
}

If we ever migrated our old flow from Charges to PaymentIntents, we would rely solely on payment_intent.succeeded