Skip to main content
This guide walks through the core IngoPay flow end to end: signing a request, verifying a card account to get a reusable token, and using that token to push a payment. The card example shown here applies structurally to every other payment type — the only differences are the account fields you send and the account_type code you use.
You’ll need your username, secret, and participant_id to follow this guide. These are issued by your Ingo integration manager during onboarding. If you don’t have credentials yet, contact your integration manager before proceeding.

​
Environments

EnvironmentBase URL
Sandboxhttps://payapi-sandbox.ingo.money
Productionhttps://payapi.ingo.money
Use sandbox credentials for all development and testing. Production credentials are issued after sandbox certification is complete.
Every IngoPay request must be signed using HMAC-SHA512. Your secret never leaves your server — it is used locally to produce a signature that Ingo verifies on each request.Before sending any request, generate these four headers:
HeaderDescription
X-DateCurrent timestamp in RFC 1123 / GMT format. Clock skew tolerance is ±300 seconds.
Content-sha512Base64-encoded SHA-512 hash of the raw request body. Use RAW output — not hex.
Content-LengthByte length of the request body.
Content-TypeAlways application/json.
Then build your Authorization header:
Authorization: hmac username="{username}", algorithm="hmac-sha512", headers="request-line x-date content-type content-sha512 content-length", signature="{signature}"
The signature is an HMAC-SHA512 hash of a string assembled from the request line and each signed header value, Base64-encoded. See Authentication for the full step-by-step construction guide.
Use RAW (binary) output from your HMAC library before Base64 encoding — not hex. Base64-encoding hex output produces an incorrect signature and a 401 Unauthorized response.
The verify call tokenizes the recipient account and runs every identity and account check configured in your risk profile — in a single request. Submit the card details; Ingo returns a customer_account_token you’ll use for all future transactions with this account.
POST /gateway/verify HTTP/1.1
Host: payapi-sandbox.ingo.money
Authorization: hmac username="test", algorithm="hmac-sha512", headers="request-line x-date content-type content-sha512 content-length", signature="hAMqhSX6eogO1QpES9Dg..."
X-Date: Fri, 17 Jan 2020 19:59:29 GMT
Content-sha512: HpXfYk7qDatRNVlGHQOv3ELyAVd+JCdUcpHB5PMnu08=
Content-Length: 245
Content-Type: application/json

{
  "participant_id": 12345,
  "account_type": "CA",
  "recipient_first_name": "Tom",
  "recipient_last_name": "Smith",
  "account": "4264531111111115",
  "expiration_date": "2212",
  "cvv": "000",
  "recipient_address1": "123 Main St",
  "recipient_city": "Smallville",
  "recipient_state": "TX",
  "recipient_zip": "93245",
  "recipient_phone": "8015555555",
  "participant_unique_id1": "VRF-0001",
  "timestamp": 1579291169,
  "version": "11"
}
A successful response returns an approved status and your token:
{
  "status": "approved",
  "participant_id": 12345,
  "customer_account_token": "cust_tok_abc123xyz..."
}
The customer_account_token never expires. Store it alongside the customer record in your system. You will use it — not raw card data — for every future disbursement and debit to this account.
Use the customer_account_token from the verify response to push funds. You never re-submit raw account data — the token is all the process call needs to identify and disburse to the account.
POST /gateway/process HTTP/1.1
Host: payapi-sandbox.ingo.money
Authorization: hmac username="test", algorithm="hmac-sha512", headers="request-line x-date content-type content-sha512 content-length", signature="kJNrpSY7fphR2PqFT0Eh9..."
X-Date: Fri, 17 Jan 2020 20:01:14 GMT
Content-sha512: BqMnXk8rEbtPLWmJIRpu5DKzBSe+NCeVdpIC6QMko19=
Content-Length: 158
Content-Type: application/json

{
  "participant_id": 12345,
  "account_type": "CA",
  "customer_account_token": "cust_tok_abc123xyz...",
  "amount": "100.00",
  "participant_unique_id1": "TXN-0001",
  "timestamp": 1579291274,
  "version": "11"
}
A successful response confirms the transaction:
{
  "status": "approved",
  "participant_id": 12345,
  "transaction_id": "ING-20200117-00001",
  "amount": "100.00",
  "customer_account_token": "cust_tok_abc123xyz..."
}
After a process call, Ingo posts a real-time webhook to your configured endpoint with the final transaction outcome. Do not rely solely on the synchronous response — some payment types complete asynchronously and the webhook carries the authoritative result.See Webhooks for payload structure, event types, and signature verification.

​
What’s next

Authentication

Full HMAC-SHA512 construction guide, header reference, and common signing errors.

Payment Methods

Delivery speeds, use cases, and eligibility across every supported payment type.

Webhooks

Event types, payload structure, and how to verify webhook signatures.

Error Reference

Status codes, decline reasons, and retry guidance.