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 forpayment.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, andrequest_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 yourc_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.
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.
