Skip to main content

Overview

GatePay payouts enable merchants to distribute funds to multiple recipients in a single batch operation. Common use cases include:
  • Commission distribution to affiliates or partners
  • Merchant settlement and revenue sharing
  • Batch fund transfers to user wallets
  • Royalty payments
  • Refunds and chargebacks

Prerequisites

Before integrating payout capabilities, you must complete the following setup steps:
  1. Application Creation: Create a GatePay application in the merchant dashboard
  2. Client ID Retrieval: Obtain your ClientId for API authentication
  3. Signing Key Configuration: Configure your signing key for request authentication
  4. Callback URL Configuration: Set up your callback endpoint for asynchronous notifications
For detailed setup instructions, see General Overview and Setup and Authentication and Security.

Payout Integration Steps

Step 1: Query Fees and Limits

Before creating any payout batch, query the current fee structure and amount limits. These values may change dynamically and should not be cached. Request:
POST /v1/pay/withdraw/query
This endpoint retrieves:
  • Current withdrawal fees
  • Minimum and maximum payout amounts
  • Per-transaction limits
  • Daily payout limits

Step 2: Create a Batch Payout

Create a batch containing one or more sub-orders (recipient withdrawal requests). Each batch is identified by a unique batch_id.

Step 3: Receive Callbacks and Track Status

GatePay sends asynchronous callbacks to your configured callback URL. These callbacks report both batch-level status and individual sub-order status. Callback Order:
  1. Initial callback when batch is created (INIT status)
  2. Processing callback when batch enters processing (PROCESSING status)
  3. Final callback with completion status (SUCCESS, PARTIAL, or FAIL)

Step 4: Reconciliation and Fallback Queries

Use the query API as a fallback mechanism for:
  • Verifying callback delivery
  • Reconciling accounts
  • Investigating failed transactions
  • Confirming final status

Callbacks First, Query as Fallback

GatePay’s payout system prioritizes asynchronous callbacks for reliability and performance:
StagePrimary MethodFallback
Batch StatusReceive callbacks to callbackUrlUse POST /v1/pay/withdraw/query to query batch status
Sub-order StatusCallbacks include sub-order detailsQuery individual sub-order details via query API
ReconciliationReceive detailed callback payloads with all amounts and feesQuery endpoint for audit trails and confirmation
Best Practice: Implement callback handling as your primary status update mechanism. Use the query API only for fallback verification or periodic reconciliation. For detailed callback information, signing, and verification procedures, see Notification Callbacks.

Idempotency and Reconciliation

GatePay uses two key identifiers for idempotency and reconciliation:
FieldScopePurposeUsage
merchant_withdraw_idPer sub-orderMerchant-assigned unique identifier for each withdrawal recipientIdempotency; prevent duplicate payouts to the same recipient
suborder_idPer sub-orderGatePay-assigned unique identifierPlatform-side tracking, callbacks, and query operations
Idempotency Guarantee: If you resubmit a batch with the same merchant_withdraw_id values, GatePay will detect duplicates and prevent double-payments.

Batch and Sub-Order Statuses

Batch Status Lifecycle

A batch progresses through the following states:
StatusDescription
INITBatch created; initial validation in progress
PROCESSINGBatch being processed; funds are being transferred on-chain
PARTIALSome sub-orders succeeded; others failed
FAILEntire batch failed; no funds were distributed
SUCCESSEntire batch succeeded; all sub-orders completed

Sub-Order Status

Each withdrawal within a batch has its own status:
StatusDescription
DONESub-order completed successfully; funds transferred and confirmed
FAILSub-order failed; funds were not transferred or were reversed

Callback Payload Structure

Main Batch Callback Payload

When a batch status changes, GatePay sends a callback with the following main-order fields:
FieldRequiredDescription
batch_idYesUnique batch identifier assigned by GatePay
merchant_idYesYour merchant ID from GatePay
statusYesCurrent batch status: INIT, PROCESSING, PARTIAL, FAIL, or SUCCESS
client_idYesThe client_id used to create this batch
pay_back_statusYesRollback/refund status for the batch
channel_idYesChannel identifier used for this payout batch

Sub-Order Array Callback Payload

Each callback includes a suborders array with detailed information about individual withdrawals:
FieldRequiredDescription
suborder_idYesGatePay-assigned sub-order identifier
chainYesBlockchain network (e.g., Ethereum, Polygon)
addressYesRecipient wallet address
currencyYesPayout currency (e.g., USDT, ETH)
amountYesRequested payout amount in currency units
feeYesActual fee deducted for this sub-order
txHashYesBlockchain transaction hash (confirms on-chain transfer)
statusYesSub-order status: DONE or FAIL
merchant_withdraw_idYesYour merchant-assigned identifier for reconciliation
fee_typeYesFee deduction type: 0 (internal) or 1 (external)
finish_timeYesCompletion timestamp (Unix epoch in seconds)
sub_amountYesTotal amount for this sub-order (including fee if applicable)
done_amountYesAmount actually credited to the recipient’s address

Fee Type Clarification

  • Fee Type 0 (Internal Deduction): Fee is deducted from the merchant’s account; the full amount is sent to the recipient.
  • Fee Type 1 (External Deduction): Fee is deducted from the withdrawal amount; the recipient receives amount - fee.

Error Handling

Common Error Codes

When creating or processing payouts, you may encounter the following error codes:
Error CodeDescriptionApplicable APIRecommended Handling
550233Insufficient balance in merchant accountBatch payout creationCheck available balance via account balance query; top up account
550234Memo/description field exceeds maximum lengthBatch payout creationCheck memo length limits and truncate if necessary
550235Amount precision exceeds allowed decimal placesBatch payout creationVerify amount precision matches currency requirements (e.g., USDT typically allows 6 decimals)
550238Batch contains too many sub-ordersBatch payout creationSplit into multiple batches with fewer sub-orders
550239amount field is missing or emptyBatch payout creationVerify amount is provided for each sub-order
550240currency field is missing or emptyBatch payout creationVerify currency is provided for each sub-order
550241address field is missing or emptyBatch payout creationVerify recipient address is provided for each sub-order
550242chain field is missing or emptyBatch payout creationVerify blockchain network is provided for each sub-order
550245batch_id already exists (duplicate batch)Batch payout creationUse a unique batch_id or leverage idempotency for retries
550249Invalid batch_id or merchant_withdraw_id formatBatch payout creationEnsure IDs are valid strings without special characters

Error Response Handling

When an error occurs, GatePay returns an error response with:
  • Error Code: Numeric identifier for the error
  • Error Message: Human-readable description
  • Details: Additional context (if available)
Implement retry logic with exponential backoff for transient errors (network issues, timeouts). For permanent errors (insufficient balance, invalid parameters), address the underlying issue before retrying.

Reconciliation and Auditing

Account Balance Reconciliation

Regularly reconcile your GatePay merchant account balance against your internal records:
  1. Query Fees Before Each Payout: Get current fee rates
  2. Track Batch Status: Monitor batch and sub-order status via callbacks
  3. Audit Amounts: Verify amount, fee, and done_amount match your expectations
  4. Reconcile Daily: Use query APIs to reconcile at end of day
For detailed reconciliation procedures, see Account Balance and Reconciliation.

Investigating Failed Payouts

If a sub-order fails:
  1. Check Sub-Order Status: Query the batch to get status for each sub-order
  2. Review Error Details: Look for error reason in callback or query response
  3. Verify Recipient Address: Ensure wallet address is valid for the specified chain
  4. Check Recipient Chain: Confirm the recipient’s wallet supports the specified blockchain
  5. Retry If Transient: For temporary failures, resubmit with a new batch_id and same merchant_withdraw_id

Query Payout Results

Request:
POST /v1/pay/withdraw/query
Query detailed results for a specific payout batch. This endpoint returns:
  • Batch status and metadata
  • Sub-order array with individual results
  • Fee information
  • Transaction hashes for on-chain verification
Use this endpoint for:
  • Fallback verification if callbacks are delayed
  • Periodic reconciliation
  • Detailed audit trails
  • Support and investigation

Request Signing and Validation

All payout requests must be signed using your configured signing key. For details on request signing, signature generation, and signature verification for callbacks, see Authentication and Security. Key signing requirements:
  • Sign the request body with your private key
  • Include the signature in the X-Signature header
  • Verify callback signatures using your public key

Best Practices

  1. Query Fees Dynamically: Always query current fees before creating a batch; do not cache fee values.
  2. Use Unique Identifiers: Assign unique merchant_withdraw_id and batch_id values to prevent duplicates and enable idempotency.
  3. Implement Callback Handling: Set up robust callback processing for real-time status updates.
  4. Monitor Batch Status: Track batches through their lifecycle; alert on PARTIAL or FAIL status.
  5. Verify Transactions On-Chain: For critical payouts, verify txHash on the blockchain explorer.
  6. Reconcile Daily: Reconcile your internal account balance against GatePay records daily.
  7. Handle Errors Gracefully: Implement proper error handling with exponential backoff for retries.
  8. Secure Your Signing Key: Protect your signing key; never expose it in logs or to unauthorized parties.
  9. Validate Recipient Addresses: Perform basic validation (checksum, format) on recipient addresses before submission.
  10. Plan for Rate Limits: Be aware of API rate limits; implement request queuing for large batch operations.