List charges
Most recent first, scoped to your business and your key's mode.
Most recent first, scoped to your business and your key's mode.
Query Parameters
1 <= value <= 20050created|pending|succeeded|failed|refunded|partially_refunded|disputed
Filter on whether the money has landed. false is money a rail has taken that you cannot spend yet. Separate from status because settlement is not a lifecycle state: a charge is succeeded the moment the rail confirms it, and whether the funds have arrived is a different question about the same charge.
Response Body
application/json
application/json
curl -X GET "https://example.com/api/b/v1/charges"[ { "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "reference": "string", "amount_minor": 0, "fee_minor": 0, "net_minor": 0, "refunded_minor": 0, "currency": "string", "status": "string", "channel": "string", "provider": "string", "failure_reason": "string", "is_test": true, "created_at": "2019-08-24T14:15:22Z", "confirmed_at": "2019-08-24T14:15:22Z", "settled_at": "2019-08-24T14:15:22Z", "expected_settlement_at": "2019-08-24T14:15:22Z", "payer_name": "string" }]Who did what, and when GET
The audit trail for this business, newest first. Ordered by `occurred_at` and then by id. Entries written in one transaction share a timestamp — it is the transaction's — so ordering by time alone would page inconsistently and could show or skip a row. Refused actions appear alongside successful ones. Filtering them out would remove the entries an investigation is usually looking for.
Create a charge POST
Take a payment. A repeated `idempotency_key` returns the original charge with 201 rather than a conflict. A client that did not hear our answer and asked again wants the charge, not an error it has to interpret.