Using Payment Links, Payment Page, payment extensions, Payouts, POS, or the Reconciliation API? View the classic product documentation
Hosted Checkout
We host the checkout. You redirect the shopper to Peach, then they come back to your site.
Create the hosted checkout
confirm: false with payment_link: true, server-side. No payment method data goes in this request — the hosted page collects it — and by default nothing in it names a payment method either, so the page offers everything the account has enabled for the currency. return_url is the page on your site the shopper comes back to when they are done, and payment_link_config controls how Peach's page looks; edit it in the panel beside the editor.
Who initiates the payment?
The two are different requests, not a flag on the same one.
The shopper is present and authorises the payment themselves. This is every other flow in this area.
One link, every method
HostedThe request narrows nothing, so the hosted page offers every method the account has enabled for this currency — and each one's redirect, QR or wallet sheet is handled there rather than by you.
The payment's payment_method_type tells you what was chosen. That is what decides the refund rule — the hosted page has no say in it.
- PayShapOne refund only
- Scan to PayFull refunds only
- Capitec PayNo refunds
- PayflexFull or partial refunds
Full rules per method are listed under Payment methods.
allowed_payment_method_types
The one place this integration names payment methods. Leave it empty and the hosted page offers everything the account has enabled — including methods added later, with no code change.
Card
Bank transfer
Pay later
Wallet
Voucher
Crypto
Hosted page appearance
Read when the checkout is created and baked into the page. Editing it once a checkout is live means creating it again.
Order details shown to the shopper
This step doesn't require an API request.