Peach Payments
Keep Peach Payments in step with your orders, invoices and payments without re-keying, with the right person approving what changes.
15 ways to read, 1 way to write, each write switched on by you.
Quality checks
Built and tested with example responses.
- Ready to connect: doneEvery listed action is built in.
- Built and tested with example responses: doneEach action is built from the provider’s published API and tested against example responses, errors, rate limits and paging.
Connected, approved, proven.
The things teams do most with Peach Payments, an example flow with a person in the loop, and what Nexra keeps as proof.
Top actions
- Create payment linkApproval by rule
- Get payout balanceRead
Example flow
- Peach Payments · Get payout balanceDone
- Peach Payments · Create payment linkNeeds approval
- Nexra · Record the decision and result in the evidence chainProven
Example workflow. Routine runs go through on their own. Only a change your rules flag, such as one over a limit you set, waits for the right person, who sees the exact change and the rule before it reaches Peach Payments.
What gets logged
- Whether it ran on its own or who approved it, and under which rule
- A fingerprint of the exact request sent to Peach Payments
- Peach Payments's reply: what it created or changed
- One entry in the evidence chain, linked to the one before
Try this in the sandbox
Run the whole flow with test data in your sandbox, then connect a Peach Payments test account before you go live.
For developers
Technical detail
Peach Payments: checkout status, payment methods, payment links and batches, reconciliation transactions, refunds and payouts (read); creates payment links.
Peach Payments API docs- Source actions
- 15
- Destination actions
- 1
- Data types
- 11
What you can map
Reads are always available. Writes are off until you switch them on for a connection, and governed writes follow your policies.
Bank verifications1
- Get bank account verification resultSource
Outcome of a bank account verification you already requested: each check is positive, negative or unverified. No account details are returned.
Bulk payout uploads1
- List today's bulk payout uploadsSource
Bulk payout files uploaded today with their processing state and payout request ID. Read only.
Checkouts1
- Read checkout statusSource
Read an existing Peach Checkout v2 status and result code.
Payment link batches2
- Get payment link batchSource
Read the status of one bulk payment-link upload.
- List payment link batchesSource
Bulk payment-link uploads for a channel with row counts and status.
Payment links3
- Create payment linkDestinationNot retried automaticallyApproval before production
Generate a Peach-hosted payment link for an invoice. No money moves until the customer pays.
- Get payment linkSource
Read a payment link's status and resulting transaction.
- List payment linksSourceIncremental
Payment links with status, amount and the resulting transaction, filtered by date and status.
Payment methods1
- List checkout payment methodsSource
Payment methods enabled on a channel for a currency.
Payout balance1
- Get payout balanceSource
Available payout float balance and last transaction date.
Payout requests3
- Get payout requestSource
Status of every payout in one payout request. Read only.
- List payout requestsSource
Payout requests and their payouts between two dates (window under three months). Read only.
- Find payout request by payout IDSource
Find the payout request that contains your merchant-supplied payout ID. Read only.
Payout webhooks1
- Get payout webhook settingsSource
Configured payout and bank-verification webhook endpoints.
Reconciliation transactions1
- List reconciliation transactionsSourceIncremental
Transactions with settlement status, settled amount and bank reference for one window of at most 24 hours.
Refunds1
- List refundsSourceIncremental
Refunds (payment type RF) from the reconciliation feed, with settlement reference, for one window of at most 24 hours. Read only.
Access and limits
- Authentication
- Peach Payments API credentials or access token
- Plans and access
- A Peach Payments merchant account with API credentials (client ID, client secret, merchant ID) from the Dashboard; payouts and reconciliation must be enabled on the account. Payment Links, Reconciliation and Payouts need the merchant ID; Checkout payment methods and payment link creation need a channel entity ID.
- Test environment
- Sandbox credentials work with testsecure.peachpayments.com; links, reconciliation, payouts and authentication then use their sandbox hosts.
- Rate limits
- Reconciliation allows one request per second; other limits are not published. HTTP 429 and Retry-After are honoured with bounded retries.
- Pagination
- Payment links and batches use offset/perPage with meta.nextOffset; other reads return one page.
- Provider events
- Peach sends checkout, payment link and payout webhooks to the URLs configured in the Dashboard or supplied per request. Flows run on demand, on a schedule, or when a scheduled check finds new or changed records.
Before you build a flow
- Intentional exclusions: payments and refunds (Payments API), checkout initiation, payment link cancellation, bulk link uploads and attachments, payout creation, bulk payouts, proof-of-payout emails, payout webhook changes and bank account verification.
- Payments API transaction queries (api-v2.peachpayments.com) are not implemented: they take the user ID and password as query-string parameters, which Nexra never sends.
- Checkout initiation (POST /v2/checkout) is not offered: it needs an allowlisted Referer domain per merchant; use payment links instead.
- Peach does not document an idempotency key for payment link creation, so an uncertain create is never repeated.
- Customer contact details, card BIN, expiry, holder and payout account numbers are not mapped.
- Not implemented by design: presigned error-file URLs (payment-link batch files and bulk payout error files) act as temporary credentials to files that can hold customer and bank details; payout transaction and statement reports are CSV downloads whose columns are not documented and may include beneficiary account numbers; proof-of-payout PDFs are binary downloads.
- Legacy Hosted Checkout status (GET /status) is not implemented: it needs a signature computed from the checkout secret in the query string; use the Checkout v2 status read.
- Payouts and fees: Peach Payments' API has no merchant settlement (payout) list and reports no fee amount. Settled transactions in the reconciliation feed (reconciliation_transactions.list) carry the settlement reference, batch number and settled amount: group them by settlement reference to rebuild a payout; the difference between amount and settled amount is what Peach deducted.
- Refunds are read from the reconciliation feed (payment type RF); Peach has no separate refund list endpoint, and its Payments API refund query needs credentials in the query string, which Nexra never sends.
- Disputes and chargebacks: Peach Payments' API has no dispute or chargeback list or query endpoint, and the reconciliation feed does not carry chargeback (CB) transactions. Disputes are handled by Peach (aggregation accounts) or your acquiring bank, outside the API.
Developer reference
- Create the Peach Payments credentials described above with the narrowest permissions your flows need.
- In Nexra, open Connect, then Connections, then New connection, choose Peach Payments, enter its settings and credentials, and tick only the write actions you need. Connection guide
- Test the connection, then use its actions as flow sources and destinations. Flow guide
Machine-readable detail: GET /api/public/connect/connectors/peach-payments and the Connections API.