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.
Surcharges
Charge a card or bank-transfer fee on top of the amount settled.
Collections
Chase invoices that have not been paid.
Dunning
Retry failed payments and escalate.
Webhooks
React to payment events in your own systems.