kepa Commerce API

A REST API for card payments. Predictable resource-oriented URLs, JSON request and response bodies, and standard HTTP verbs, response codes, and authentication. Take payments in person from a provisioned Android terminal or online with a hosted checkout and secure browser fields.

Start building→API reference Ways to integrate →

Surfaces

Choose the guide for where you take payment. In-person payments start on an Android terminal; online payments start on your server and finish in the customer’s browser.

Card present

Take tap, insert, and PIN payments from a provisioned Android terminal.

35 endpoints · device bearer token

Card not present

Online checkout. Your server creates the intent; the customer's browser completes it with a publishable key.

33 endpoints · api.kepapay.co

Example request

Start with a working request, then follow the guide for retries, completion, and recovery.

cURL

The secure Android payment rail sends encrypted card data to the Go engine.

curl https://api.kepapay.co/api/v1/terminal/transactions/authorize \
  -H "Authorization: Bearer $KEPA_DEVICE_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "deviceId": "dev_123", "terminalId": "TID-00012345",
        "amount": 2500, "currencyCode": "USD", "transactionType": "purchase",
        "entryMode": "Chip", "completionMode": "CONTACT_CHIP_SECOND_AC",
        "panEncrypted": "<device-encrypted>", "accountDataKsn": "<account-ksn>" }'

# → { "approved": true, "authorizationCode": "A12345",
#     "responseCode": "00", "transactionId": "txn_01JQ…" }

How an in-person payment works

Card data stays in the payment terminal. kepa authorizes the payment and returns one payment ID that you use for receipts, refunds, and support.

Collect the card

step 1

The Android terminal handles tap, insert, card prompts, and PIN.

Android terminal

Authorize

step 2

Send the amount and terminal-encrypted card data to the kepa API.

https://api.kepapay.co

Recovery

step 3

If a response is lost, check the original attempt instead of charging again.

/api/v1/terminal/transactions/recovery

See full topology diagrams →

Capabilities

The API spans the payment lifecycle: accept, route, bill, and settle.

Accept

In person, online, or server-to-server. One integration across every surface, including saved cards on file.

Orchestrate

Soft declines retried, unavailable acquirers routed around. Cascading and failover across processors, on by default.

Bill

Soon

Save a card, run subscriptions, raise invoices, and let customers self-serve from a billing portal.

Settle

Settlement, reconciliation, and payouts, with a ledger readable from the API.

Server and browser

Card-not-present splits across two credentials: the server creates the intent, the browser confirms it. This keeps your secret key out of the browser and card data off your server.

Your server

Create a payment intent or checkout session with your secret key. You get back a client secret — the only part the browser is allowed to see. Start at /v1/cnp/payment-intents.

The customer’s browser

Tokenize the card, run 3DS if the issuer asks, and confirm — all under /api/v1/cnp/public/ with a publishable key. Apple Pay and Google Pay use the same session.