Create hosted payment links, accept configured wallet and gateway methods, and follow every payment state through webhooks or merchant-scoped status verification.
One API, two environments. The request mode and credential prefixes select sandbox or live processing. The merchant ID is always derived from the credentials and must never be sent in the request body.
Authentication
Every request is authenticated with a mode-matching client ID and client secret. Keep both credentials on your server and send JSON explicitly.
Environment-aware API integration GatePay supports sandbox testing and live production processing through the same endpoints. Always complete payment, redirect, status, and webhook testing in sandbox before switching your server integration to live credentials.
Environment configuration
Sandbox mode
Use for: Development, integration testing, simulated provider outcomes, and webhook verification.
Request mode:sandbox
Credentials:ci_test_... and cs_test_...
Processing: Uses sandbox merchant and payment records. No real provider charge or wallet balance movement occurs.
Live mode
Use for: Production payment links, real gateway processing, and customer wallet payments.
Request mode:live
Credentials:ci_live_... and cs_live_...
Processing: Uses production merchant records and the payment gateways configured by the GatePay administrator.
01Choose the modesandbox uses the sandbox database. Live uses production services.02Match the credentialsci_test_ / cs_test_ or ci_live_ / cs_live_.03Send JSON headersUse JSON Accept on every request and JSON Content-Type on POST requests.
Required headers
Header
Value
Required
Description
Accept
application/json
Yes
Required on POST and GET.
Content-Type
application/json
POST
Required for payment creation.
X-Client-Id
ci_test_...
Yes
Merchant application client ID.
X-Client-Secret
cs_test_...
Yes
Merchant application client secret.
Security notice Never expose your Client Secret in client-side code. Store the Client ID and Client Secret securely on your server.
Quick start
A complete integration starts on your server and ends with webhook verification or a status lookup. The hosted checkout handles the customer-facing payment step.
01Generate credentialsCopy sandbox or live credentials from the approved merchant application.02Create the linkPOST payment information and the allowed payment method names.03Redirect customerOpen the returned payment_url in the customer browser.04Process returnRead trx_reference and your original reference from the merchant URL.05Verify paymentUse the signed success webhook or poll by your merchant reference.06Handle idempotentlyDeduplicate webhook deliveries and safely handle repeated callbacks.
Merchant setup and credentials
The REST API is available through an Express merchant application. GatePay creates credentials for the merchant mode, while every request remains scoped to the authenticated application and its owning merchant.
Merchant dashboard
One Express merchant, mode-specific credentials
Open Merchant, select the Express merchant, and use App Info / Merchant Credentials to copy the client ID and secret. Credentials are server-side secrets and must never be exposed in browser or mobile application code.
Merchant typeExpress
Required statusApproved
Owner statusActive
Credential sourceApp Info
Register or create an Express merchantFrontend merchant registration creates the Express merchant application and its initial mode-specific credential pair.
Complete approvalThe Express merchant must be Approved, and its owning GatePay user must be Active in both sandbox and live requests.
Copy credentials securelyUse the client ID and client secret from App Info / Merchant Credentials only from your backend server.
Rotate when necessaryCredential regeneration requires verification. After rotation, the previous client ID and secret stop authenticating immediately.
Environment credential matrix
Mode
Client ID
Client secret
Data and processing
sandbox
ci_test_...
cs_test_...
Merchant application and payment records use the sandbox database. Provider outcomes are simulated and no wallet balance moves.
live
ci_live_...
cs_live_...
Merchant application and payment records use production data and configured live gateway processors.
Credential mode is enforced. The mode in the request body, both credential prefixes, and the database containing the merchant application must agree. Mixed or mode-incompatible credentials are rejected before payment data is stored.
Currency and gateway rules
GatePay administrators control currency, payment-method, and fee availability. The payment_methods array requests full method names, but it cannot enable a gateway that is inactive, unsupported, or not configured for Merchant payment.
Admin-managed availability. The GatePay administrator must activate each supported payment method for Merchant payment. Only activated methods can be requested by an authenticated REST API merchant.
Runtime decision order
01
Validate the currency
The currency code must exist, be Active, and have the Fiat type. Crypto currency records are not accepted as the payment currency.
02
Resolve every requested method
Names are matched case-insensitively against active GatePay payment methods with an implemented REST API processor.
03
Apply Merchant payment activation
The administrator must activate every requested method for Merchant payment for the selected fiat currency.
04
Apply Wallet requirements
Mts follows the Wallet payment flow. Live payments require an eligible payer wallet, while sandbox payments use demo wallet outcomes.
05
Calculate Merchant payment fees
Gateway percentage and fixed charges come from the Payment_Received transaction type shown as Merchant payment, then the merchant group fee and fee-bearer rule are applied.
The GatePay administrator must activate every requested method for Merchant payment.
Mts requires an active logged-in payer with an eligible wallet. MTN is a guest, asynchronous checkout. Cybersource uses Secure Acceptance Hosted Checkout (same as deposit and invoice) and settles only after signature validation with decision=ACCEPT and reason_code=100. PayUmoney sandbox links require INR.
Mtn provider prerequisites
MTN uses the administrator-configured provider mode and the credentials required by that mode; a public HTTPS callback URL and the MTN reconciliation scheduler are also required.
The REST payment remains pending after RequestToPay is accepted and becomes final through polling, callback verification, or scheduled reconciliation—even if the customer closes the tab.
Merchant receiver wallet
No wallet check is performed when the payment link is created.
After a successful live payment, GatePay creates the merchant currency wallet if it does not already exist, then credits it once.
All methods must pass. If one requested payment method is unavailable, GatePay rejects the complete request with HTTP 422 and returns unavailable_payment_methods. It never silently removes a method from the payment link.
POST
Create payment link
Creates a hosted checkout link for an approved merchant, active fiat currency, and payment methods enabled for merchant payment.
https://gatepay.techvill.net/api/v1/payments
Credentials requiredSandbox and liveActive fiat currency
Payment method selection. Send full method names such as Stripe, Paypal, Mts, Mtn, or Cybersource. External gateways must be active for merchant payment and the selected currency. Cybersource additionally requires active Payment Received fees and limits plus Secure Acceptance Hosted Checkout credentials (profile_id, access_key, secret_key, mode).
Request body
Field
Type
Required
Description
mode
string
Yes
sandbox or live.
amount
string
Yes
Positive decimal with up to eight decimal places.
currency
string
Yes
Active three-letter fiat currency code.
payment_methods
array
Yes
One or more unique payment method names.
reference
string
Yes
Your unique reference, up to 100 characters.
success_url
URL
Yes
Return URL for success and pending outcomes.
webhook_url
URL
Yes
Public endpoint for payment lifecycle events.
cancel_url
URL
Yes
Return URL for failed and cancelled outcomes.
description
string
Optional
Payment description, up to 1000 characters.
metadata
object
Optional
Up to 20 scalar key-value pairs.
Merchant ID is prohibited. GatePay derives the merchant from the authenticated application. Live URLs must use HTTPS, and callback_url is not accepted; use success_url.
Idempotency: Repeating the same reference with the identical payload returns the existing link with HTTP 200. Reusing it with changed data returns HTTP 409.
GET
Verify transaction status
Fetches the current public transaction status using the exact merchant reference supplied during link creation. A found transaction always returns HTTP 200.
Redirect the customer to the returned payment_url. The checkout shows only payment methods saved on that transaction and validates the selected method again before processing.
SUCCESSReturns to success_url.PENDINGReturns to success_url while processing continues.FAILEDReturns to cancel_url.CANCELLEDReturns to cancel_url.EXPIREDUnstarted link passed its stored expiry.
Return URL data. GatePay preserves existing merchant query parameters and appends only trx_reference and reference. Treat browser returns as informational and use webhooks or status verification for fulfillment.
Webhooks
GatePay posts lifecycle events to the webhook_url stored on the payment link. Sandbox and live use the same contract, with delivery records stored in their originating environment.
Supported events
Event
Public status
Body signature
payment.status.created
PENDING
Yes
payment.status.success
SUCCESS
Yes
payment.status.failed
FAILED
Yes
payment.status.cancelled
CANCELLED
Yes
payment.status.expired
EXPIRED
Yes
Delivery headers
Header
Description
X-Event
Lifecycle event name.
X-Delivery-Id
Unique ID used to deduplicate at-least-once deliveries.
X-Timestamp
Unix timestamp used to verify the event signature.
Webhook signatures. Every event contains a signature field. It is HMAC-SHA256 of timestamp + "." + unsigned compact JSON body using the matching client secret. Reject timestamps older than five minutes.
Retry policy: Any 2xx response acknowledges delivery. GatePay retries connection failures, timeouts, 408, 429, and 5xx responses immediately, then after 1 minute, 5 minutes, 15 minutes, and 1 hour. Other 4xx responses and redirects are terminal.
Sandbox testing
Sandbox checkout never calls a real provider or changes a wallet balance. Select an enabled method and use one of the demo values below to produce a deterministic result.
Provider rules. Stripe and Flutterwave accept listed test cards. MTN uses its local phone simulator. Cybersource uses the generic success, failed, pending, and cancelled simulator in API sandbox mode; live-mode links use Secure Acceptance Hosted Checkout like deposit and invoice. PayUmoney sandbox payments require INR. Bank is not supported by the REST API.
Wallet
WLT-1000000001SUCCESS
WLT-1000000002FAILED
WLT-1000000003PENDING
WLT-1000000004CANCELLED
WLT-1000000005INSUFFICIENT BALANCE
Stripe
Card NumberMM/YYCVC
424242424242424208/28123SUCCESS
400000000000000208/28123FAILED
400000000000999508/28123PENDING
400000000000006908/28123CANCELLED
PayPal
success@paypal.testSUCCESS
failed@paypal.testFAILED
pending@paypal.testPENDING
cancelled@paypal.testCANCELLED
Flutterwave
Card NumberMM/YYCVV
553188665214295008/28123SUCCESS
553188665214295108/28123FAILED
553188665214295208/28123PENDING
553188665214295308/28123CANCELLED
CoinPayments
BTCSUCCESS
ETHFAILED
USDTPENDING
LTCCANCELLED
PayUmoney
payu-successSUCCESS
payu-failedFAILED
payu-pendingPENDING
payu-cancelledCANCELLED
Payeer
P-SBX-100001SUCCESS
P-SBX-100002FAILED
P-SBX-100003PENDING
P-SBX-100004CANCELLED
Coinbase
cb-successSUCCESS
cb-failedFAILED
cb-pendingPENDING
cb-cancelledCANCELLED
MTN
46733123450FAILED
46733123451PENDING
46733123452EXPIRED
46733123453SUCCESS
Cybersource
successSUCCESS
failedFAILED
pendingPENDING
cancelledCANCELLED
Sandbox & Go Live Checklist
Use this checklist before moving from simulated payments to live checkout. The same REST endpoints work in both environments; the request mode and the complete client credential pair must change together.
Sandbox readiness
Validate the complete integration without calling a real provider or moving wallet balances.
Send mode=sandbox with matching ci_test_... and cs_test_... credentials.
Test successful, failed, pending, cancelled, insufficient-balance, and expired outcomes where supported.
Confirm checkout returns, reference-based status polling, webhook signatures, deduplication, and retry handling.
Use only documented simulator values; sandbox never calls production gateway processors.
Live readiness
Enable real payment processing only after merchant access and production configuration are complete.
Send mode=live with matching ci_live_... and cs_live_... credentials.
The Express merchant must be Approved and its owning user must be Active.
Use an Active fiat currency and only methods enabled by the administrator for Merchant payment.
Configure production gateway credentials and public HTTPS success, webhook, and cancel URLs.
Production launch checks
Required before live traffic
Credentials and modeUse the live client ID and secret together with mode=live. Never mix test and live prefixes.
Merchant accessVerify the Express merchant is Approved and the merchant owner remains Active.
Currency and methodsConfirm each fiat currency is Active and every requested method is enabled for Merchant payment.
Gateway readinessConfigure production credentials and merchant-payment fees for every external gateway offered at checkout.
Wallet flowMts payers need login, an eligible wallet, and enough balance. A missing merchant receiver wallet is created after successful settlement.
Secure merchant URLsUse public HTTPS success, webhook, and cancel URLs, and safely handle the two returned reference parameters.
Webhook receiverVerify every event HMAC with the matching client secret, reject stale timestamps, deduplicate delivery IDs, and return 2xx quickly.
Verification and operationsPoll status by the exact merchant reference, run webhook queue and scheduler or cron processing, and monitor failed delivery attempts.
Switch the complete environment together. Do not change only mode or one credential. Change mode, client ID, and client secret as one set, keep merchant_id out of the request, and complete a low-value live payment before opening general traffic.
Errors and limits
Every JSON response uses the existing GatePay response envelope. The HTTP status represents request handling; transaction outcomes returned from status verification still use HTTP 200.
HTTP
Machine code examples
Meaning
401
invalid_credentials
Missing or invalid credential pair.
403
credential_mode_mismatch
Credential mode mismatch or unavailable merchant access.
404
transaction_not_found
No transaction for this app and exact reference.
406
not_acceptable
Accept header does not allow JSON.
409
reference_conflict
Reference exists with a changed payload.
415
unsupported_media_type
POST request body is not JSON.
422
validation_error
Invalid payload or unavailable payment configuration.
429
rate_limit_exceeded
Configured request limit was exceeded.
503
sandbox_unavailable
Requested sandbox service is unavailable.
Error response format
{
"response": {
"status": {
"code": 422,
"message": "The request payload is invalid."
},
"records": {
"code": "validation_error",
"errors": {
"currency": ["The selected currency is invalid."]
}
}
}
}
Admin-managed policies. The default rate limit is 60 requests per minute. New links use the current 15, 30, 45, or 60 minute expiry preference, while existing links retain their stored expiry.