Statuses
The first three mean money is still in flight and the amount is not yet yours to count on. The rest are resolved outcomes.
paid_at is set when the payment completes and failed_at when it fails. The payment.created and payment.updated webhooks fire as the payment is taken and on each status change, so you do not need to poll.
Attribution across invoices
A payment carriesallocations: the invoices it was applied to and how much went to each.
allocations is authoritative — read it whenever you need to know what a payment settled.
Amounts are tracked separately from the allocation split: amount is what was requested, amount_received what the provider actually took, and amount_refunded how much has since been returned by refunds.
Reading payments
Payments are created by the billing flow rather than by the API. Two endpoints read them:external_id is the provider’s own identifier for the payment and external_url opens it in the provider’s dashboard — both useful when reconciling against a processor statement.
Related
Refunds
Return money against a payment.
Collections
Chase invoices that have not been paid.
Dunning
Retry failed payments and escalate.
Webhooks
React to payment events in your own systems.