> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bafanglaicai88.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Describe only the public 123hub merchant API documented on this site. The primary endpoint is POST /public/api/multihub/v1.
> Preserve API method names, field names, header names, and error codes exactly as documented. Do not invent endpoints or parameters.
> Treat every amount as an integer in minor units unless a page explicitly states otherwise.
> Never expose, request, or fabricate a merchant secret key. The SDK pages contain reference implementations, not official SDK packages.
# Changelog
> Track changes and updates to the 123hub API
# API Changelog
Stay informed about new features, improvements, and breaking changes to the 123hub API.
Subscribe to our developer newsletter to receive changelog updates via email.
## 2026
### July 2026
#### v2.3.1 - Replay Header Compatibility
**Replay headers remain optional**
* `X-Data-Timestamp` and `X-Data-Nonce` are an optional pair for every signed API method, including ticket, refund, chargeback, and attachment methods
* Requests with neither replay header remain valid; sending only one header, a stale timestamp, or a reused nonce remains invalid
* `X-Data-Application-Id` and the exact-body `X-Data-Hash` signature remain required and unchanged
#### v2.3.0 - Public Support API v1
**Public Support API v1**
* Added strict signed API methods for merchant tickets, merchant-visible comments, and safe ticket attachments
* Added idempotent full/partial `refund.request` with exact digit-string minor-unit amounts through signed PostgreSQL `bigint` max, public refund IDs, history, summaries, and comments
* Added read-only chargeback history, summaries, evidence metadata, and short-lived authorized downloads
* Added optional timestamp/nonce replay validation, API-key scopes, method quotas, cursor pagination, and stable numeric support errors
* Added opt-in durable webhook events for ticket, refund, and chargeback changes; existing subscriptions and default scopes are unchanged
* Rollout is controlled per resource and canary application; disabled methods remain unavailable without changing existing payment API behavior
* Hardened attachment finalization and cleanup with bounded validation capacity, exact-size reads, fail-closed scanning, and opaque legacy evidence identifiers
#### v2.2.22 - Rich Deposit Receiver Instructions
**Rich Deposit Receiver Instructions**
* `payment.in` responses can now return allowlisted P2P instructions in `payment.receiver`: bank name/code, receiver phone, document type/number, and QR payload
* Provider-specific metadata is not exposed; Studio integrations must normalize provider fields into the documented `bankDetails.*` targets
* Existing `receiver.bank_account`, `payment.redirect` and UPI deep-link contracts remain backward compatible
#### v2.2.21 - API Credential Usage Limits
**API Credential Usage Limits**
* Successful signed API requests now update credential lifetime and UTC-day usage counters
* Enforced credential daily limits return HTTP `429` with code `3009`; rollout starts in observe mode so would-be rejections can be audited first
* Developer Center reports daily usage separately from the lifetime request count
#### v2.2.20 - Catalogue-backed Payment Routes
**Catalogue-backed Payment Routes**
* `payment.in` now accepts newly provisioned payment-method routes from the platform catalogue without requiring a gateway release for each method code
* Malformed payment-method payloads return validation code `9000`; unavailable or unconfigured methods return method-not-available code `1002` instead of a generic `1000`
* Method/configuration rejection happens before payment persistence, so invalid routes do not create failed payment records
* Existing `service_id` request contracts and signatures are unchanged
#### v2.2.19 - Request Correlation
**Request Correlation**
* The response body `request_id` now always matches the `X-Request-ID` response header
* Payment creation logs link `request_id` to the returned payment `h_id` for operational investigations
* Caller-provided `X-Request-ID` values remain diagnostic aliases and do not replace the server-generated identifier
* No breaking API changes
#### v2.2.18 - Webhook Delivery Reliability
**Webhook Delivery Reliability**
Webhook delivery and API error handling received reliability improvements.
* Improved merchant callback retry behavior for temporary delivery and platform errors
* `payment.notification` now queues callbacks for asynchronous delivery instead of waiting on merchant webhook endpoints
* Webhook resend authentication errors now return the standard API error envelope instead of a generic server error
* No breaking API changes
### June 2026
#### v2.2.16 - Payment Creation Reliability
**Payment Creation Reliability**
Payment creation and webhook delivery received reliability improvements for merchant integrations.
* Increased the default payment creation timeout from 15s to 30s for `payment.in` and `payment.out`
* Improved webhook callback delivery reliability and response handling
* Improved payment request handling under slower provider responses
* No breaking API changes
#### v2.2.15 - Removed legacy hosted payment pages
**Removed legacy hosted payment-page endpoints**
The legacy gateway-hosted payment-page surface has been removed. The platform routes all payments through external providers, so customer redirects are returned directly in the API response (`payment.redirect`) rather than via gateway-hosted pages.
* Removed `GET /payment-pages/:token`, `GET /payment-pages/:token/details`, and the `GET /payment-pages/:token/events` SSE stream
* These endpoints were no longer produced by any active payment flow; integrations should use the `redirect` URLs returned by `payment.in`/`payment.out`
#### v2.2.14 - Webhook Signature Binding
**Webhook Signature Binding**
Outgoing webhooks now include a stronger replay-bound signature and safer resend behavior.
* Added `X-Webhook-Signature-V3`, an HMAC-SHA512 signature over timestamp, nonce, delivery id, and raw body
* Existing `X-Webhook-Signature-V2` and `X-Data-Hash` headers remain available for backward-compatible verification
* Manual payment notification resends now use a unique delivery id while keeping the public payload `id` stable
* Hosted payment page generation now fails closed when signing or public URL configuration is missing
#### v2.2.13 - Studio Deposit Requisites
**Studio Deposit Requisites**
Studio-backed bank-transfer deposits can now return provider bank requisites in the payment creation response.
* `payment.in` responses may include `result.payment.receiver.bank_account` when a Studio provider returns IBAN/account details
* Existing redirect and UPI response formats are unchanged
* No breaking API changes
#### v2.2.12 - Credential IP Enforcement
**Credential IP Enforcement**
Merchant credentials with `allowed_ips` now enforce the configured exact IP/CIDR allowlist on 123hub API requests.
* Requests outside the credential IP allowlist return API error `3006` with HTTP `400`
* Empty `allowed_ips` remains unrestricted for backward compatibility
* Existing route policy behavior for `allowed_currencies` and `allowed_service_ids` is unchanged
#### v2.2.11 - Credential Route Policy
**Credential Route Policy**
Merchant production credentials can now be limited by currency and specific `service_id` routes for payment creation.
* Added credential access policy for `payment.in` and `payment.out`
* Empty policy remains unrestricted for backward compatibility
* Policy failures return API error `3008` (`CREDENTIAL_POLICY_DENIED`) with HTTP `403`
* Webhook signing secret selection is unchanged
### May 2026
#### v2.2.10 - Payout Limits & Webhook Delivery Reliability
**Payout Limits & Webhook Delivery Reliability**
Payment and payout flows received reliability improvements and clearer limit guidance.
* Clarified `payment.out` failure handling for insufficient balance (`6004`), monthly payout limits (`6005`), daily payout limits (`6006`), and other payout-limit rules such as since-last-settlement limits (`6035`)
* Documented that daily and monthly payout limits reset in the merchant timezone
* Improved webhook delivery recovery for events left in a retrying state
* Added webhook delivery coverage for refunded payment lifecycle callbacks
* Improved webhook delivery safety by requiring a signing secret before callback delivery
* Improved balance read reliability for signed merchant integrations
* No breaking API changes
#### v2.2.9 - Webhook Completion Timestamp Correction
**Webhook Completion Timestamp Correction**
Outgoing payment and payout webhooks now report final success time from the confirmed provider completion timestamp.
* `data.result.payment.timestamps.finished` now prefers `confirmed_at` for successful terminal payments
* Success status history entries now use the same final provider confirmation time
* `processed_at` remains the processing/initiation timestamp for async provider payouts
#### v2.2.8 - Legacy API-Key Surfaces Removed
**Legacy API-Key Surfaces Removed**
Public merchant integrations now use signed signed API requests only.
* Removed legacy `X-API-Key` authenticated `/api/v1/balance` and `/api/v1/webhooks` endpoints
* Removed gateway websocket payment event broadcasts
* Kept `balance.get`, `payment.notification`, outgoing signed webhooks, and signed webhook resend available through signed API authentication
#### v2.2.7 - Application Rate Limits
**Application Rate Limits**
Valid merchant application keys now have high protective application-level ceilings for core public methods.
* Added separate throttle buckets for `payment.in`, `payment.out`, `payment.status`, and `balance.get`
* Keyed API throttles by merchant and application instead of client IP address
* Configured payment creation buckets as abuse/runaway protection rather than normal operating limits
* Throttled signed API requests now return HTTP `429` with the standard error envelope
#### v2.2.6 - Webhook Contract Drift Fixes
**Webhook Contract Drift Fixes**
Payment and payout webhook delivery now uses the same `data.result.payment` envelope for automatic callbacks, manual `payment.notification` re-sends, and template test webhooks.
* `payment.notification` now resolves non-numeric `h_id` by exact payment lookup instead of fuzzy search
* Manual notifications now preserve failed, expired, and refunded lifecycle payloads
* Test webhook OpenAPI documentation now shows the current SHA-512 headers and callback envelope
#### v2.2.5 - Balance Endpoint Recovery
**Balance Endpoint Recovery**
Merchant balance reads were restored for API-key clients.
* Added `GET /balance` for a merchant currency balance
* Added `GET /balance/all` for all merchant balances
* Documented both endpoints in the generated OpenAPI spec
### April 2026
#### v2.2.4 - API Secret Webhook Signing
**API Secret Webhook Signing**
Outgoing webhook signing now uses the merchant API secret for newly created or rotated webhook configurations.
* Documented webhook verification as `SHA512(rawBody + API secret)`
* Added `api_secret`, `api_secret_version`, and `key_id` to API secret rotation responses
* Kept legacy `secret`, `secret_key`, and `secret_version` fields as deprecated compatibility aliases
* Existing legacy webhook configurations continue to verify with their previously issued signing secret until API secret rotation
#### v2.2.3 - Public Contract Validation Sync
**Public Contract Validation Sync**
Public request validation and generated schema were reconciled.
* Documented payment amounts as integer minor-unit values in the OpenAPI schema
* Clarified per-payment `webhook_url` as an absolute public HTTP(S) URL with protocol
* Added validation coverage for fractional payment amounts and protocol-less webhook URLs
#### v2.2.2 - Webhook Resend & Routing Reliability
**Webhook Resend & Routing Reliability**
Added merchant-facing recovery controls and improved payment routing reliability.
* Added `POST /payments/{paymentId}/webhook/resend` to re-queue webhook delivery for a specific payment
* Added a 10 requests/minute throttle to webhook resend requests
* Improved deposit routing reliability with automatic provider fallback when cascade routing is enabled
* Expanded accepted signed API request fields for payer, receiver, bank, redirect, identifiers, and per-payment `webhook_url`
* Tightened per-payment `webhook_url` validation to require a valid public HTTP(S) URL
* Fixed webhook consumer handling for queued delivery payloads
**Breaking changes:**
* Per-payment `webhook_url` now must be a valid public HTTP(S) URL
#### v2.2.1 - Documentation Contract Sync
**Documentation Contract Sync**
Public documentation was reconciled with the current gateway contracts.
* Added dedicated reference pages for API methods, outgoing webhooks, webhook management, and public payment pages
* Corrected `payment.status` and `payment.notification` lookup identifiers to `c_id` and `h_id`; `p_id` is returned for reconciliation and is not a lookup key
* Corrected Mexico payout examples: CLABE is sent in `receiver.bank.account.id`; `receiver.bank.clabe` is not accepted by the DTO
* Reworked webhook payload docs to use `data.result.payment`, omit internal `_payment_id`, and document `X-Data-Hash` plus replay-protection headers
* Documented actual webhook delivery defaults: timeout 30s, `max_retries` default 3, `retry_delay_seconds` default 1, jittered exponential retry with a 24h cap
* Expanded the error code reference to cover every current `PaymentApiErrorCode`
* Documented successful API response signing with `X-Data-Hash`
#### v2.2.0 - Turkey Direction & Payment Method Expansion
**v2.2.0 -- Turkey (TRY) Payment Direction & Documentation Refresh**
New payment direction for Turkey and updated documentation to reflect actual system capabilities.
**New: Turkey (TRY) deposits:**
* Currency: `TRY` (Turkish Lira)
* Payment methods: `havale` (bank transfer), `papara` (e-wallet), `kredikarti` (credit/debit card)
* Deposits: `havale` (bank transfer), `papara` (e-wallet), `kredikarti` (credit/debit card)
* Withdrawals: `bank_transfer` with IBAN
**New: Additional currencies:**
* `AUD` (Australian Dollar) -- deposit & withdrawal
* `LKR` (Sri Lankan Rupee) -- deposit & withdrawal
**New payment methods documented:**
* `upi` -- Unified Payments Interface (India, primary deposit method)
* `havale` -- Turkish bank transfer (Havale/EFT)
* `papara` -- Papara e-wallet (Turkey)
* `kredikarti` -- Turkish credit/debit card
* `imps` -- Immediate Payment Service (India)
**New: `payment.notification` method documented:**
* Re-send webhook notification for a specific payment
**Webhook documentation corrected:**
* Webhook payload now documents the delivered outer envelope (`id`, `data`, `created_at`, `merchant_id`) and keeps internal `_payment_id` out of merchant-facing examples
* Documented fields absent in webhooks vs API (`service_id`, `description`, `redirect`, `receiver.bank`)
**Response documentation expanded:**
* Added `operations[]` and `operation` fields to response reference
* Added `receiver.bank_account` format for deposit responses (TRY, ARS)
* Documented `redirect.to` type variations by region (array for UPI, string for Havale)
* Clarified `status.error` type as `integer | string | null`
* Noted `h_id` format varies by provider (numeric string or UUID)
* Documented that `receiver.bank` is not returned in `payment.status` or webhooks
**Documentation corrections:**
* Removed currencies with no active provider: BRL, CNY, COP, EUR, GEL, USD
* Changed INR default method from `bank_transfer` to `upi`
* Turkey (TRY) supports both deposits and withdrawals (not deposit-only)
* Added region-specific bank fields: IFSC (India), CLABE (Mexico), bank code (Argentina), IBAN (Turkey)
**Breaking changes:**
* None (additive only; removed currencies were never functional)
### February 2026
#### v2.1.0 - Error Handling & Response Format Improvements
**v2.1.0 — Error Handling, Balance, and Validation Improvements**
Improved API compatibility with the 123hub specification. Error handling, response formats, and validation have been updated.
**HTTP status codes (breaking change):**
* Error responses now return **HTTP 400** (previously HTTP 200)
* Unknown method errors (`1002`) return **HTTP 404**
* Successful responses continue to return HTTP 200
* Always check the `success` field to determine the outcome
**Error response format:**
* `error.details` and `error.context` are now always present in error responses (value is `null` when not applicable)
* Missing required field errors now use code `1005` with descriptive `details` object
* Wrong hash/signature errors now return code `3000` (Authentication error)
* `next` field removed from response envelope
**New validation errors:**
* `6001` — Incorrect transaction amount (zero or negative)
* `6002` — Incorrect currency code (mismatch with `service_id`)
* `6009` — Payment already exists (duplicate `c_id`)
* Missing `payer` object in `payment.in` now returns `1005` with specific description
**`gateway.ping` format change (breaking change):**
* Response changed from `"result": "pong"` to `"result": {"message": "pong"}`
**`balance.get` format change (breaking change):**
* Response restructured from `result.balances[]` to `result.balance.{id, amounts[], enabled}`
* Balance fields renamed: `available` → `value`, `frozen` → `value_freezing`, added `value_blocking` and `enabled`
**Redirect URLs:**
* Provider HTTPS payment page URLs are no longer included in `redirect.to`
* Only UPI deep-link URLs (for India) are returned in `redirect.to`
**Breaking changes:**
* HTTP status codes for errors changed from 200 to 400/404
* `next` field removed from response envelope
* `gateway.ping` response format changed
* `balance.get` response structure completely changed
* Error code for missing fields changed from 9000 to 1005
* Error code for wrong hash changed from 3002 to 3000
### January 2026
#### v2.0.0 - 123hub API Migration
**v2.0.0 — 123hub API Migration (Breaking Change)**
Complete API redesign to 123hub.pro format. This is a **breaking change** — all integrations must be updated.
**New API format:**
* Single endpoint: `POST /public/api/multihub/v1` replaces all previous REST endpoints
* Method-based routing via `body.method`: `payment.in`, `payment.out`, `payment.status`, `balance.get`, `gateway.ping`
* Standardized response envelope: `{ success, result, error, request_id, processing_time }`
* Success returns HTTP 200, errors return HTTP 400/404
**New authentication:**
* `X-Data-Application-Id` (integer) + `X-Data-Hash` (SHA512) replaces `X-API-Key`
* Webhook signatures changed from HMAC-SHA256 to SHA512 with `X-Data-Hash` header
**New concepts:**
* `service_id` — integer mapping to provider + payment method combination
* `c_id` / `h_id` / `p_id` — structured payment identifiers
* Numeric error codes (1000-9000) replace HTTP status code-based errors
**Removed:**
* REST endpoints (`POST /api/v1/payments`, `GET /api/v1/balance`, etc.)
* `X-API-Key` authentication
* P2P payment infrastructure (account-service, sms-service, qr-service)
* Team management functionality
* Device management functionality
#### v1.5.0 - In-Request Webhooks
**Per-Payment Webhook URL**
You can now pass a webhook URL directly in the payment creation request, enabling per-payment notification routing without pre-configuring webhooks.
**New Features**
* **`webhook_url`**: Optional field in `POST /payments` — specify a URL to receive webhook events for this specific payment
* **`webhook_events`**: Optional array to choose which events to subscribe to (defaults to `payment.created`, `payment.completed`, `payment.failed`)
* **Automatic deduplication**: If the same merchant sends the same `webhook_url` across multiple payments, the system reuses the existing webhook configuration
* **Webhook signing secret**: In-request webhooks were originally signed with a per-merchant signing secret; current deliveries use the merchant API secret after API secret rotation
**How it works**
* Pass `webhook_url` (and optionally `webhook_events`) when creating a payment
* The system automatically creates (or reuses) a webhook endpoint for your merchant
* Events are delivered to both admin-configured webhooks and in-request webhooks in parallel
* In-request webhooks use SHA512 signature verification (updated in v2.0.0 from HMAC-SHA256)
**API Changes**
* `POST /payments` now accepts optional `webhook_url` (string, max 2048 chars) and `webhook_events` (string array)
* In-request webhooks are excluded from `GET /webhooks` listing by default (use `?source=in_request` to view them)
* Merchant detail response included the legacy `default_webhook_secret` field
**Breaking changes**
* None (backwards compatible)
#### v1.4.0 - Webhook Security & Contract Stabilization
**Webhook Payload Whitelist**
Improved security and API contract stability for webhook payloads.
**Changes**
* `customer_data` in webhook payloads now uses a **whitelist approach** — only specific, documented fields are included
* Internal processing data (IP addresses, user agents, internal IDs, processing metadata) is no longer sent to merchant webhooks
* `payout` object is now only included for `withdrawal` type payments (not for deposits)
**Allowed customer\_data fields**
* Top-level: `note`, `customer_email`, `customer_phone`, `customer_name`, `external_id`, `reference`, `description`, `expires_at`, `requested_payment_type`
* `commission`: `currency`, `total_minor`
* `payout` (withdrawals only): `bank_code`, `bank_account`, `recipient_name`, `bank_name`
**Breaking changes**
* Webhook payloads no longer include internal fields that were previously exposed unintentionally
* If your integration relied on undocumented fields in `customer_data`, you may need to update your webhook handler
***
## 2025
### December 2025
#### v1.3.0 - Customer Management System
**Customer Base & Payment Linking**
New customer management system that enables tracking and analytics across payments.
**New Features**
* **Customer ID**: Merchants can optionally pass `customer_id` when creating payments to link to an existing customer
* **Auto-linking**: When `customer_id` is not provided, customers are automatically created/matched by email or phone
* **Customer Data in Response**: Payment responses now include `customer` object with `id`, `email`, `phone`, `name`
**API Changes**
* `POST /payments` now accepts optional `customer_id` field (integer)
* Payment responses include `customer_id` and `customer` object
* `customer` object in request body remains required (name, email, phone)
**Breaking changes**
* None (backwards compatible)
#### v1.2.2 - Payment Page Enhancements
**Standalone Payment Page & Return URL Support**
Major improvements to the hosted payment page experience.
**New Features**
* **Return URLs**: Merchants can now provide `success_url` and `cancel_url` for merchant settings for automatic redirect after payment completion
* **Mercado Pago Integration**: Quick-pay button with deep link support (mobile devices only)
**Technical Changes**
* Improved bundle size and performance
* Fixed SSE event handling for real-time payment status updates
* Payment page now correctly updates UI when payment status changes via SSE
**API Changes**
* `GET /payment-pages/:token/details` now returns `return_urls` object with `success_url` and `cancel_url`
**Breaking changes**
* None (backwards compatible)
#### v1.2.1 - API Consistency & Validation
**API key format alignment and validation improvements**
This release fixes inconsistencies between API validation, documentation, and Swagger schemas.
**API Key Format Changes**
* Standardized API key format validation:
* Test keys: `qp_test_sk_*` (e.g., `qp_test_sk_abc123...`)
* Production keys: `qp_prod_sk_*` (e.g., `qp_prod_sk_xyz789...`)
* Removed support for deprecated formats: `qp_sandbox_sk_*`, `qp_live_*`
* Updated all documentation and Swagger examples to reflect correct key formats
**Payment Status Updates**
* Added `refunded` and `partial_refund` statuses to payment API schemas
* Payment pages now correctly display refund statuses
* DTOs and filters now support filtering by refund statuses
**Withdrawal Validation**
* `recipient_name` and `bank_account` are now required fields for withdrawal requests for ARS flow.
* Improved error messages for missing payout details
* Consistent validation across all withdrawal types
**Documentation Fixes**
* Payment page URLs are now documented as dynamic (vary by currency/method/region)
* Updated all code examples with correct API key formats
* Clarified payout field requirements for different countries
**Breaking changes**
* API keys using `qp_sandbox_sk_*` or `qp_live_*` formats will no longer be accepted
* Withdrawal requests without `recipient_name` or `bank_account` will return `400 Bad Request`
***
### November 2025
#### v1.2.0 - Production Stability Release
**Major improvements**
Following the successful scaling deployment, we shipped a set of optimizations based on real world usage patterns.
**Improvements**
* Optimized payment processing pipeline for higher throughput
* Increased rate limits for payment creation to **5000 requests per minute** (burst: **500 requests per 10 seconds**)
* Improved webhook delivery reliability and retry mechanism
* More descriptive error messages for validation failures
**Performance**
* Reduced average API response time by about 40%
* Faster payment status transitions
**Breaking changes**
* None
**Enhanced testing and quality of life**
* Improved consistency of API responses across endpoints
**Breaking changes**
* None
**Optimization and refactors**
* Internal architecture improvements for better scalability
* Enhanced payment method validation rules
* Improved balance calculation accuracy
**Breaking changes**
* None
***
### October 2025
#### v1.1.0 - Webhooks Improvements
**Webhook manager improvements**
**New features**
* Enhanced webhook signature binding for improved security and verification
**Developer note**
* Make sure your webhook handlers are idempotent to safely handle retries.
**Breaking changes**
* None
**Webhook delivery fixes**
* Fixed webhook signature generation for consistent verification on client side
* Improved webhook retry logic with exponential backoff
* Enhanced request binding for webhook payloads
**Breaking changes**
* None
**Payment limits update**
* Corrected maximum amount validation rules
* Improved amount formatting in API responses
**Breaking changes**
* None
**Production deployment optimizations**
* Enhanced API key handling and validation
* Improved error responses for invalid credentials
* Added support for additional payment method configurations
**Breaking changes**
* None
**Deprecation notice**
* API key formats `qp_sandbox_sk_*` and `qp_live_*` are deprecated and will stop working in December 2025
* Please use the standard formats: `qp_test_sk_*` for test mode, `qp_prod_sk_*` for production
***
### September 2025
#### v1.0.2 - Integration Fixes
**Webhook flow corrections**
* Fixed `payment.completed` webhook not being sent in some scenarios
* Improved webhook scheduling reliability
* Enhanced stale webhook detection and cleanup
**Breaking changes**
* None
**Balance and withdrawal improvements**
* Resolved issues with balance calculations
* Fixed withdrawal validation edge cases
* Improved payment and requisite lock expiry handling
**Breaking changes**
* None
**API key and proxy compatibility**
* Fixed API key validation in specific edge cases
* Improved proxy compatibility by handling `X-Forwarded-Host` headers
* Strengthened request validation
**Breaking changes**
* None
**Documentation updates**
* Updated API documentation with corrected parameters
* Removed redundant request parameters
* Improved example payloads
**Breaking changes**
* None
***
### August 2025
#### v1.0.1 - Private Beta Improvements
**Payment processing enhancements**
* Improved SPEI transfer handling
* Enhanced bank account validation (CLABE format)
* More informative error messages for invalid bank accounts
**Breaking changes**
* None
**Webhook reliability improvements**
* Added automatic retry for failed webhook deliveries
* Implemented webhook event deduplication
* Enhanced HMAC-SHA256 signature verification
**Developer note**
* Webhook receivers should remain idempotent due to retries and deduplication.
**Breaking changes**
* None
**Balance API enhancements**
* Added `/balance/all` endpoint for multi-currency support
* Improved balance precision handling
* Added `available` and `pending` balance breakdown
**Breaking changes**
* None
***
### July 2025
#### v1.0.0 - Initial Release
**Public API v1.0.0 release**
Public release of the 123hub Payment Gateway API.
**Core features**
* Payment creation (deposits and withdrawals)
* Multiple payment methods support
* Hosted payment pages (`deposit_pp`, `withdrawal_pp`)
* Real time webhook notifications
* Balance inquiry API
* Test and production modes via API key prefixes (`qp_test_sk_*`, `qp_prod_sk_*`)
**Supported payment methods**
* `bank_transfer` - bank transfers (Argentina, Uruguay)
* `spei` - Mexican interbank transfers (SPEI)
* `oxxo` - cash payments at OXXO stores
* `card` - credit and debit cards (tokenized)
* `cash` - cash payments
* `crypto` - cryptocurrency payments
**Supported currencies**
* `ARS` - Argentine peso
* `UYU` - Uruguayan peso
* `MXN` - Mexican peso
**Webhook events**
* `payment.created` - payment initialized
* `payment.completed` - payment successful
* `payment.failed` - payment failed
* `payment.cancelled` - payment cancelled
* Withdrawals use the same `payment.*` events with `destination: "out"`
**Private beta launch**
* Initial API endpoints for selected partners
* Core payment functionality
* Basic webhook support
* Authentication via API keys
***
## Versioning Policy
The 123hub API uses semantic versioning:
* **Major versions** (v1, v2) indicate breaking changes
* **Minor versions** add new features that are backwards compatible
* **Patches** include bug fixes and minor improvements
### Breaking changes
We strive to minimize breaking changes. When they occur:
1. We announce them at least 1 month in advance
2. We provide migration guides
3. We support the previous version during a transition period
### Deprecation policy
Deprecated features will:
* Be announced in the changelog
* Continue working for at least 3 months
* Return deprecation warnings in API responses when possible
## Migration Guides
When breaking changes occur, we will publish detailed migration guides here.
***
Check current API status and subscribe to incident updates.