Boundless Developer Docs

V1.0Last updated 22 September 2026

Boundless lets you accept payments on behalf of your business and your locations through a single REST API. These guides cover the in-store (card-present) channel — taking a payment on a physical terminal in one of your stores.

If you already accept online payments with Boundless, the in-store channel adds two things you have not needed before: a store and terminal to take the payment at, and an asynchronous outcome — the customer taps their card at the device, so the result arrives after the request that started it, not in the same response.

How an in-store payment works, in one paragraph

Your billing application asks the Boundless API to take a payment at a named store and terminal. Boundless sends the bill to the terminal and immediately returns a payment that is waiting at the device. The customer taps their card; when they are done, Boundless tells your application the outcome — by webhook, or by a status call you make yourself. The card never touches your application.

What you will do to integrate

1. Authenticate with an API key.
2. Register your stores and terminals so Boundless knows where a payment is being taken.
3. Take a payment and follow it to its outcome.
4. Reverse a payment — cancel a waiting bill, or void a paid sale on the spot.
5. Receive outcomes through webhooks, and trace any payment end to end when a question comes up.
6. Work through the go-live checklist before your integration review.
7. Consult the API reference for the exact requests and responses.

Base URL

All requests in these guides go to the production API:

https://api-live.kcpboundless.com

Conventions

• Amounts are decimal values in the payment's currency (for example 100.00), sent alongside an ISO 4217 currency (for example SGD).
• Identifiers you choose — your own reference for a store, a terminal, or a bill — travel with the payment so you can match an outcome back to your records.
• Identifiers Boundless issues — payment ids, pspReference — are opaque strings. Do not parse, derive, or construct them.
• Times are ISO 8601 in UTC.

Revision history

The version shown above (and in the sidebar) is the latest entry here; it moves with every update to these docs.

Version	Date	Change
V1.0	22 September 2026	First versioned issue: reversals (cancel and void), payment history and tracing, the go-live checklist, and expanded retry and reliability guidance.