Drive the terminal from your software.

Connect an existing POS, ERP, or application to a PAX terminal, read the merchant's transactions, orders, employees, and work orders, and embed online ordering — all through the POS Velocity API.

Open the API Reference →See a live round trip ↓
Two developers working on code in a bright office
ECR · one requestPOST/api/v2/ecr/terminal/payment
POST/api/v2/ecr/terminal/payment
Simulated in your browser · real ECR endpoint and payload shape
or try
you sendone request, out of your own software
Requestterminal-payment
# payment of $48.20 on a PAX terminal
POST …/terminal/payment?serial=<terminal>
x-api-key: <your-api-key>
x-idempotency-key: <uuid>
{ "amount": 4820,
"externalId": "order-1042" }
we answerthe card is already run by the time you read it
Responseapplication/json
200 OK · application/json
{ "status": "completed",
"result": { "status": "approved" },
"amount": { "approved": 4820 },
"card": { "brand": "AMEX", "last4": "1003" },
"processor": {
"authorizationCode": "7796" } }
→ if the line drops:same key, same answer
Retryx-idempotency-key
# lost the answer? same key, same body
POST …/terminal/payment
x-idempotency-key: <the same uuid>
← 200 OK
{ "idempotent": true,
"result": { "status": "approved" } }
# or fetch the command by id
GET /api/v2/ecr/requests/{id}
Send any amount with the button or Enter — cents on the wire, carried back exactly as typed. Key in 505 for a decline.

Your POS. Our terminal. One request.

Keep the system your staff already use. Send an amount to the PAX terminal and receive a structured result with authorization status, masked-card details, and references for supported follow-up operations.

The integration is designed to keep raw card data within the configured terminal and payment flow rather than passing it to the partner POS.

terminal-payment.sh
# charge $48.20 on the merchant's PAX terminal
POST /api/v2/ecr/terminal/payment?serial=<terminal>
x-api-key: <your-api-key>
x-idempotency-key: <uuid>

{ "amount": 4820, "externalId": "order-1042" }

# -> the terminal runs the card, you get:
200 OK
{ "status": "completed",
  "result": { "status": "approved", "code": "000000" },
  "amount": { "approved": 4820 },
  "card": { "brand": "VISA", "last4": "3492" },
  "processor": { "authorizationCode": "8731" } }

GraphQL, REST, ECR and OpenAPI.

Four ways into the one platform POS Velocity Ltd. builds and runs — the same one behind the terminal and the back office.

Keep scrolling
Code editor showing application source code01 · GraphQL

GraphQL API

Query the platform for supported custom integrations — so your own software can read the ledger.

  • Typed queries
  • Custom integrations
Business owner working on a laptop in a cafe02 · Merchant REST

Merchant REST API

Authenticate with one API key and work against request and response shapes documented in the live reference.

  • API-key access
  • Scoped keys
  • Live reference
Open the reference →
Barista taking a customer's order at the counter03 · ECR

ECR terminal control

Send an amount; the terminal runs chip, tap and PIN and returns the result with the auth code, masked card, and host reference.

  • Chip · tap · PIN
  • Host reference
  • Voids & refunds
Code editor showing application source code04 · OpenAPI

OpenAPI 3.1

The whole reference as one OpenAPI 3.1 document, in JSON or YAML — for client generators and AI assistants. Assistants that speak MCP can also search it live at /api/docs/v2/mcp.

  • JSON · YAML
  • Client generators
  • MCP server
Open the document →

Safe to retry. Never charged twice.

Every money command carries an idempotency key. If the connection drops mid-payment, send the same key and body again and you get the first attempt's stored answer — not a second charge.

A decline is still a 200 with the result inside. A terminal that cannot be reached answers 503 and leaves the key unused. Any command can also be fetched by its id.

retry.sh
# the connection dropped: same key, same body
POST /api/v2/ecr/terminal/payment?serial=<terminal>
x-idempotency-key: <the same uuid>

200 OK
{ "idempotent": true,
  "status": "completed",
  "result": { "status": "approved" } }

# or fetch the command by its id
GET /api/v2/ecr/requests/{id}

Four ways to plug in.

Embed online ordering

Drop our storefront web component onto any site — menu, cart, and checkout, styled to the merchant's brand.

See online ordering →

Read the ledger

List and fetch transactions, orders, employees, terminals, and work orders — every payment comes back with the references you need to reconcile it.

Manage terminals

List terminals, switch one into SEMI mode, resync it, ping it, print to it, and close its batch — from your own software.

API-key access

One key per integration, created in Settings → Developers. Each key carries only the scopes you tick, an optional expiry date, and an on/off switch.

Integrations for the tools you use.

Payment links, maps, SMS, and email are built in; the REST, GraphQL, and ECR APIs connect everything else.

  • REST + ECROpenAPI 3.1 reference
  • GraphQLTyped queries
  • Payment links3-D Secure checkout
  • SMS & emailReceipts, links & alerts
  • MapLibreLive device maps
  • Embeddable storefrontOne web component
Since 2018Toronto · CATerminal · Cloud · APIOne platform

POS Velocity is our own platform — designed, built and operated by POS Velocity Ltd. in Toronto.

Since 2018 our team has worked inside payment processing and point-of-sale software, and saw the same thing at every counter: payments in one system, orders in another, staff on paper and reports in a spreadsheet — with the merchant left to stitch them together.

So we built the whole stack ourselves: the app on the terminal, the cloud behind it, the back office and the API. Payments, orders, staff, customers and reporting share one system, so the pieces fit because they were made to — not bolted together afterwards.

— The POS Velocity team

Every endpoint. Documented and live.

Every request and response shape in one reference — browse them, and try them straight from the page.

2
API planes
7
Resource groups
1
API key
Open the API Reference →

For your dev team.

What is the ECR API?

It lets your own POS, ERP, or app drive a PAX terminal. Send an amount, the terminal runs chip, tap, and PIN, and you get back a structured result — auth code, masked card, and the host reference for later voids or refunds.

Does card data touch my software?

The ECR flow is designed so raw card data is handled within the configured terminal and payment services rather than passed to the integrated POS application.

What if the connection drops in the middle of a payment?

Every money command carries an idempotency key. Send the same key and body again and you get the first attempt's stored answer, not a second charge. You can also fetch any command by its id, and the merchant API lists and fetches the transactions with their references.

Can I embed online ordering in my own site?

Yes. The storefront ships as a web component you can drop onto any site — menu, cart, and checkout styled to the merchant's brand.

How does API authentication work?

You create an API key in the portal under Settings → Developers and send it in the x-api-key header. Each key carries its own scopes — for example reading transactions, taking a payment, or closing a batch — an optional expiry date, and an on/off switch.

Tell us what you're building.

Drive a terminal, embed a store, or read the ledger — bring your use case and we'll map it to the API on a quick technical call.

Talk to integrations →Call (877) 773-1001
30-minute walkthroughReal PAX terminalNo commitment