txn_) is the central object of the Core API: it groups what the buyer is paying
for (the items) and how they are paying (the payments). Each payment represents an
attempt/payment method (card, boleto, or Pix). The transaction status is never set directly — it
is always calculated from the aggregate state of its payments.
All routes require the
x-api-key header (your sandbox key). See
Authentication. The examples below use the sandbox base URL
https://api.sandbox.z2pay.com.Endpoints
| Method | Route | Description |
|---|---|---|
GET | /transactions | Paginated list of transactions, with filters |
GET | /transactions/:id | Fetches a transaction with its payments and items |
GET | /transactions/:id/items | Lists only the transaction’s items |
POST | /transactions | Creates a new transaction |
POST | /transactions/:id/refund | Refunds all paid payments of the transaction |
Transaction status
The status is derived from the payments through a central calculation. In summary (rules evaluated in order):How the status is calculated
How the status is calculated
- Payments with status
replacedordeletedare ignored in the calculation. - If the transaction has a zero value →
paid. - If there is no active payment →
pending. - If all non-failed payments are
refused→refused. If all arefailed/expired→failed. - Among valid payments (excluding
refused/failed/expired): if all arechargeback→chargeback; if all arecanceled→canceled; if all arein_protest→in_protest. - If the amount effectively paid covers the total transaction amount →
paid(even with a partial refund of the excess). - If there is an amount paid (> 0) less than the total and no refund activity →
partially_paid. - If the settled legs are all in a refund cycle: all
refunded→refunded; somepartially_refunded→partially_refunded; otherwise →waiting_refund. - Remaining paid/held amount alongside active refund →
partially_refunded. - Refunded amount covers the total →
refunded. - Nothing paid and the amount waiting for payment covers the total →
waiting_payment. - If none of the above apply →
pending.
| Status | Meaning |
|---|---|
pending | Created, with no confirmed payment and no defined waiting payment |
waiting_payment | Awaiting payment (boleto/Pix issued, or payment created without processing) |
partially_paid | Part of the amount was paid, but not the total |
paid | Total amount paid |
refused | Payment refused |
failed | Terminal failure at the gateway |
canceled | Canceled |
waiting_refund | Refund requested, awaiting processing |
partially_refunded | Part of the paid amount was refunded |
refunded | Total amount refunded |
chargeback | Subject to a chargeback |
in_protest | In protest (chargeback dispute in progress) |
Since the status aggregates payments, a transaction with more than one payment (e.g., two cards, or
Pix + card) may go through intermediate states such as
partially_paid or partially_refunded.Create transaction
POST /transactions
Creates a transaction. You always provide the customer and at least one item. The payments
are optional:
- With
paymentsand processing data (creditCard/boleto/pix) → payments are processed immediately at the gateway. - With
paymentswithout processing data → payments remain awaiting processing. - Without
payments→ the transaction stayswaiting_payment.
Idempotent endpoint. Send the
Idempotency-Key header (TTL of 7 days) to ensure that retries
of the same request do not create duplicate transactions. See Conventions.Important business rules
Request body
ID of an existing customer (
cust_). Mutually exclusive with customer.Inline customer data. Mutually exclusive with
customerId.Your reference code for the transaction (1 to 255 characters). Use it to correlate with your
own system.
List of items (minimum 1).
Payment methods. If omitted, the transaction stays
waiting_payment.ISO 4217 currency code (3 letters, e.g.,
BRL). Default: company configuration or BRL.Redirect URL after payment (valid URL).
Buyer’s IP address.
Free-form transaction metadata (key-value object). Searchable via the
metadataSearch filter.Maximum number of installments allowed (integer, minimum 1).
Override for the routing configuration (optional).
Example: create a Pix transaction
The item costs
9990 cents (R$ 99.90) and the payment totals 9990 — the sums match, so the
request is valid.Response
201 Created. The JSON example is illustrative — verify the actual fields in your environment’s response.Example: create and charge with a tokenized card
Two items at
5000 × 2 = 10000 cents; the payment totals 10000. The sums match. The card is
sent as a token (generated by the Tokenizer) — never send raw card
data to the Core API.List transactions
GET /transactions
Returns a paginated list. All filters are optional and can be combined.
Query parameters
Page number (pagination). See Conventions.
Items per page.
Filter by transaction status.
Filter by currency.
Filter by payment method.
Transaction ID (partial match, ILIKE).
Filter by your reference code.
Filter by customer name.
Filter by customer email.
Filter by customer document.
Combined search across customer name/email/document.
List of recipient IDs (comma-separated) that must appear in any split of the transaction.
Full-text search across any value stored in
additionalInfo.Generic search.
Start date. ISO 8601 with timezone (e.g.,
2026-06-01T00:00:00.000Z).End date. ISO 8601 with timezone.
Date field used by
startDate/endDate. Values: createdAt, paidAt, refundedAt,
canceledAt, chargedbackAt, protestedAt.Sort field. Values:
createdAt, paidAt, amount, status, customerName.Sort direction. Values:
asc or desc.Example
The exact format of the pagination envelope is described in Conventions. The JSON
above is illustrative.
Fetch transaction by ID
GET /transactions/:id
Returns the complete transaction data, including its payments and items.
Transaction ID (
txn_).Calculated transaction status. See the table in Transaction status.
Transaction items.
404. See Errors.
List transaction items
GET /transactions/:id/items
Returns only the items (products/services) of the transaction, under a data key.
Transaction ID (
txn_).404.
Refund transaction
POST /transactions/:id/refund
Creates refund requests for all paid payments of the transaction at once. The approval behavior
depends on the company’s refund.auto_approve setting (default: enabled):
- With auto-approve: the refund is created, approved, and processed at the gateway immediately.
- Without auto-approve: the refunds remain pending manual approval.
Transaction ID (
txn_).Refund reason (1 to 4000 characters).
Possible responses
200— refunds created and processed.404— transaction not found.409— no refundable payment found (e.g., no payment is in a paid state).
See also
Payments
Details of each payment method within the transaction.
Refunds
Refunding a specific payment and partial refunds.
Tokenizer
Generate the card
token before creating the transaction.Split
Configure payouts per payment with
split or splitId.Customers
Register customers to reuse via
customerId.Webhooks
Receive notifications of transaction status changes.

