The maximum plaintext block size is 501 bytes, and each ciphertext block is 512 bytes.
Blocks are encrypted or decrypted in source order and concatenated in the same order.
Encryption sequence: JSON UTF-8 bytes -> RSA/PKCS#1 v1.5 encryption -> Base64 encoding -> Hex encoding of the Base64 string.
Decryption sequence: Hex decoding -> Base64 decoding -> RSA/PKCS#1 v1.5 decryption -> UTF-8 JSON.
JSON is serialized using json.dumps(data) and then UTF-8 encoded. After decryption, the UTF-8 string is parsed as JSON.
The fixed test vectors in the documentation may be used directly for integration testing.
For the official sample code, refer to the Python example in the API documentation.
first_name and last_name are required and must not be empty.
card_address as a whole is optional. If provided, every nested field except address_line_two is required.
Address fields support letters, digits, spaces, and hyphens (-) only. Chinese characters and special characters such as commas, periods, #, and @ are not supported.
The area code, mobile number, and email address are optional and currently have no format restrictions.
The API does not restrict the number of decimal places in the input, but business processing and storage retain two decimal places.
Standard rounding is used. For example, 1.234 is processed as 1.23, and 1.235 as 1.24.
Callers are advised to submit amounts with two decimal places. Any excess decimal places will be rounded automatically.
A given API may be called up to 100 times per minute and 86,400 times per day by the same subject.
Sliding windows are used: the minute window covers the most recent 60 seconds, and the daily window covers the most recent 24 hours.
The maximum number of concurrent connections is 1,000.
The official materials currently list only Sandbox and Production. Please confirm whether a separate UAT environment exists.
If there is no separate UAT environment, please confirm whether OpenAPI version 1.0.0 is the current Production contract version and explain any Schema or behavioral differences between Sandbox and Production.
If Production differs from the confirmed Sandbox contract in RSA direction, key size, block processing, or encoding, please list the differences.
The rate-limit values, sliding windows, concurrency cap, and absence of Retry-After have been recorded. Please confirm whether the "same subject" used for rate limiting is calculated by AppId, account, sub-account, outbound IP, or a combination of these dimensions.
Maximum plaintext block size: 501 bytes.
Ciphertext block size: 512 bytes.
Blocks are encrypted or decrypted in source order and concatenated in the same order.
Encryption sequence: JSON UTF-8 bytes -> RSA encryption -> Base64 encoding -> Hex encoding.
Decryption sequence: Hex decoding -> Base64 decoding -> RSA decryption -> UTF-8 JSON.
JSON is serialized using json.dumps(data) and then UTF-8 encoded.
It is known that the same Request ID returns Duplicate, does not return the result of the first request, and that there is currently no unified operation-status query API.
Confirm whether Request ID deduplication registration and the business transaction are atomic.
Confirm whether the Request ID is registered and consumed during IP allowlist verification, authentication, rate limiting, Hex/Base64/RSA decryption, parameter validation, and the stages before and after business processing begins.
flow_id has been confirmed as globally unique, but the mapping between Request ID and flow_id remains to be confirmed. In addition to response-header echoing and internal logs, please confirm whether Request ID is written to Card Flow, Transaction, Webhook, or financial-detail records.
If Request ID is not written to final-fact tables, please confirm whether another immutable ID exists that can associate a write request one-to-one with its final fact.
The maximum length is 64 characters.
Letters, digits, and -, _, ., and : are permitted.
The uniqueness scope is AppId + ClientRequestId.
The field takes effect and consumes the ClientRequestId only after the request has passed authentication and decryption and entered the business API logging path.
It is currently retained permanently.
The same Request ID returns Duplicate Client Request Id regardless of whether the parameters are the same.
The result of the first request is not returned.
If two requests with the same Request ID arrive concurrently, only one is allowed to enter business processing; the others return Duplicate.
There is currently no unified operation-status query API.
Whether an Authorization approved before a card enters CANCELLED can still result in a Settlement after the freeze, and, if so, how funds are debited and queried.
Whether automatic card-balance return and card deletion are part of the same atomic transaction.
Whether deletion fails and rolls back in full if the automatic balance return fails.
Which flow_id or financial relationship field corresponds to the automatic balance return.
Whether a late Settlement can still debit funds after card deletion and, if so, the funding source, the representation of a negative balance or recovery, and the query and reconciliation method.
Refunds and authorization reversals can still be credited to the card after it is frozen.
/deleteCard is irreversible.
A card may still be deleted if it has a balance or pending authorizations.
The card balance is returned before deletion.
A late merchant refund is credited to the card if the card is active.
A late merchant refund is credited to the account ledger if the card has been deleted.
The automatic refund performed when deleting a card is credited to the account ledger.
A late Settlement generally does not occur after card deletion. If a merchant forces a debit, the funds are deducted from the account ledger and generally cannot be recovered.
The related fund movements can be queried and reconciled through financial details.
No signature, Callback Secret, Nonce, independent Event/Delivery ID, or mTLS is currently provided.
The earlier position was that ordinary Webhooks are evaluated by HTTP status code, the response Message is not mandatory, the timeout is 30 seconds, up to three attempts are made in total, retries occur after a timeout, and delivery order is not guaranteed.
Before Production launch, the fixed outbound IP/CIDR and IPv4/IPv6 ranges, as well as the address-change notification process and overlap period between old and new addresses, must be confirmed.
Clarify which HTTP status codes indicate successful receipt.
Clarify whether the maximum of three total attempts also applies to non-success HTTP status codes, along with the retry interval and maximum delivery period.
Clarify how delivery logs may be viewed and how manual redelivery is performed.
VM API asynchronous callbacks have a 30-second request timeout, but the queue is currently configured for one attempt. Status and error information are recorded after a failure; three automatic attempts should not be promised externally.
Transaction-flow Webhooks currently make up to three attempts in total. HTTP 4xx/5xx responses, network or connection errors, timeouts, and response bodies that do not match the success format are treated as delivery failures and retried.
No fixed retry interval is currently configured. Actual retry times depend on queue scheduling and Worker load; neither a fixed interval nor a strict maximum delivery period is guaranteed.
VM API asynchronous callbacks provide a delivery-record table that can record request_id, callback_url, request body, response code, response body, status, failure reason, sending time, and other information.
Transaction-flow Webhooks currently rely primarily on failure logs and queue logs and do not provide a complete successful-delivery query table.
Whether Request ID deduplication registration and the business transaction are atomic.
Whether Request ID is written to Card Flow, Transaction, Webhook, or financial-detail records; if not, whether another immutable ID exists that can associate a write request one-to-one with its final fact.
Whether DECLINED and other failure statuses in /getCardFlow are always final and have no fund or card-status side effects, or whether compensation, rollback, or late success may still occur.
Whether any write API can return success before the business operation has reached a final state.
The maximum propagation delay after a successful write for card, Flow, Transaction, or financial facts, and when an empty query result may be treated as mature negative evidence.
X-Client-Request-Id deduplication is registered in VM API logging middleware and is not part of the same database transaction as subsequent business-table writes. Its atomic consistency with the business transaction therefore cannot be guaranteed.
This ID is not written as a stable field to final-fact tables such as Card Flow or Transaction. VM API asynchronous callbacks preferentially use it as the callback request_id, but it is not a one-to-one relationship key for transaction, fund, or card facts.
/getCardFlow queries fund flows such as card funding and card-balance returns to the account; it does not query the purchase transaction lifecycle.
DECLINED means that the fund flow failed, PENDING means that it is being processed, and COMPLETE means that it completed. DECLINED may be treated as the failure status of that Flow, but it cannot by itself establish the final fund outcome of the complete end-to-end process.
For some write APIs, a successful response means only that VM API or the card service has accepted the request successfully or completed the current synchronous processing step. It does not mean that every subsequent channel status, fund settlement, late transaction, or asynchronous callback is final.
The client must not determine the final outcome solely from a successful write-API response. It should rely on subsequent queries, callbacks, balances, and transaction or fund flows.
There is currently no fixed maximum propagation delay that can be committed to externally.
At which stages or statuses an approved Authorization may still result in a Settlement after the card is frozen, and whether the funds are then debited from the card's available balance or the account ledger.
Whether automatic card-balance return before deletion and the deletion operation are part of the same atomic transaction; if the automatic return fails, whether the deletion fails in full and the original card status is retained.
Whether the target Production product generates a card refund with a unique flow_id when automatically returning the balance upon deletion, and whether a stable relationship field exists between that flow, the /deleteCard request, and the financial details.
If a late Settlement leaves the account underfunded, how the API or console represents a negative value, freeze, debt, or another restricted state, and whether a structured alert is provided.
Freezing or deleting a card only prevents new Authorizations.
An Authorization that was approved before deletion and has not yet been settled or fully reversed may still be submitted by the merchant for Settlement.
A late Settlement is first debited from the card balance. If the card balance is insufficient, it is debited from the main account ledger.
The automatic card-balance return before deletion and the deletion operation are part of the same atomic transaction. If the automatic return fails, the deletion fails in full and the original card status is retained.
The account ledger may display a negative amount in the console.
If the account balance is insufficient, the card issuance API returns error code 700004.
No structured alert is currently provided.
Whether it is available in Sandbox.
The integration method and authentication model.
Token or link validity, one-time-use rules, and invalidation rules.
Required request fields and the list of masked response fields.
type = "card recharge" in /getCardFlow: funds transferred from the platform account to the card.
type = "card refund" in /getCardFlow: card balance returned to the platform account.
type = "Refund" in /cardTransaction: merchant purchase refund.
type = "Reversal" in /cardTransaction: purchase authorization reversal.
