Skip to main content
Most merchants don’t want a payments integration; they want to get paid. A payment link is one API call (or one dashboard form) that produces a URL. Your customer opens it and pays on a page Chipper hosts, in your branding, over whichever rail they have. Two objects, one checkout:
Send url to the customer. That’s the integration.

​
Create a page

Omit amount and the page asks the payer what to pay.

​
What the payer sees

Your name, logo, and accent colour; the amount; and one of three flows:
  • Mobile money: picks their operator, enters their number, taps Pay. An approval prompt hits their phone. This is the only rail that charges on click.
  • Bank transfer: taps Get account details. A dedicated virtual account is set aside for this payment; they transfer the exact amount from their own banking app; we detect it. Partial amounts count and accumulate.
  • Stablecoin: picks USDC or USDT and a network, gets an address with a QR code and the exact crypto amount at a locked rate (90 minutes for stablecoins), plus a “send only USDC on Solana” warning.
Every attempt is a checkout session (cs_…) with its own countdown (5 min mobile money · 30 min bank · 15–90 min crypto). A failed or expired session never affects the link; the payer just picks another method. On success they get a receipt they can download.

​
Branding rules

accentColor can be any hex. The checkout paints it in exactly two places, the identity mark and the pay button, with the text colour computed for contrast, so no colour can break the page. logoUrl (square) and businessName complete the identity.

​
Knowing you’ve been paid

  • Webhooks: the link’s payment settles through the normal rails, so you receive collection.completed and account.credited; for bank and crypto sessions the checkout deposit fires them too.
  • Polling: GET /v1/payment-links/{id} → status: "paid", with sessions showing every attempt and which one succeeded.
  • Dashboard: Payment links → the link → Checkout sessions.
redirectUrl on the link sends the payer back to you after success (with a 5-second countdown they can skip).

​
Closing and expiry

PATCH /v1/payment-links/{id} { "status": "closed" } stops further attempts. expiresAt on creation does it on a schedule. Pages close the same way; they never “expire”; an expired page simply refuses new checkouts.

​
Sandbox

Everything above works on sandbox with pl_test_ ids and simulated money. The checkout page carries dev tools in local development to complete, partial-pay, fail, or expire a session on demand; via the API, POST /v1/simulations/checkout-deposit pays a bank-transfer session.