Skip to main content

API Methods

All API methods are sent to one endpoint:

Request Envelope

The API also accepts method as { "const": "balance.get" } and numeric-string service_id values. Payment identifiers must be strings; numeric c_id and h_id values are rejected to avoid precision loss.

Application Rate Limits

Authenticated merchant applications have separate per-method protective rate-limit buckets for payment.in, payment.out, payment.status, and balance.get. Buckets are keyed by merchant and application, not by client IP address. The payment creation buckets are configured as high safety ceilings for runaway or abusive traffic, not as normal operating limits. When a bucket is exhausted, the endpoint returns HTTP 429 with the standard API error envelope and Retry-After-* rate-limit headers.

Support, refund, and chargeback methods

The following strict method-discriminated requests use the same endpoint, signature, response envelope, and request_id as payment methods. They accept only canonical dot-notation names and never accept service_id, merchant_id, actor, source, or application ID in the body. Start with Support API fundamentals, then use the resource guides for tickets, refunds, chargebacks, attachments, and support webhooks.

payment.in

Creates a deposit.

Required Fields

Optional Fields

Example

payment.out

Creates a withdrawal/payout.

Required Fields

Region-Specific Bank Fields

receiver.bank.clabe is not part of the current request DTO. For Mexico, send the CLABE in receiver.bank.account.id.

Tracking

The create response returns your c_id, a 123hub h_id, and, when available, an opaque provider p_id. Use c_id or h_id with payment.status; payout webhooks also include these identifiers under data.result.payment.identifiers. Provider-specific callback fields such as order_id, transaction_id, session_token, or user_id are not part of the public API contract.

Example

payment.status

Returns the current payment state.
At least one lookup identifier is required:

payment.notification

Queues a webhook re-delivery for a payment and returns the same payment result shape as payment.status. The delivered merchant webhook uses the same envelope as automatic lifecycle webhooks: data.success, data.result.payment, data.next: null, data.request_id, and data.processing_time. The public webhook id stays payment/event-stable; durable delivery idempotency uses operation_id when supplied.
operation_id is optional but recommended. Reuse it only for an exact retry; a changed intent needs a new value. Without it, the compatibility identity is derived from the payment, canonical request and current minute. The method is limited to 10 requests per minute. service_id is optional; stored payment metadata is preferred.

balance.get

Returns balances for the authenticated merchant. value_blocking and enabled are currently constant runtime compatibility fields: value_blocking is always 0, and enabled is always true at both the balance and currency levels.
Response:
All balance values are integers in minor units.

gateway.ping

Validates authentication and connectivity.
Response:

Payment Response Object

Status Values