Card Issuing

Updatedcard_limit field requirements in Create Card

• Adjusted validation rules for card_limit in Create Card API, introducing BIN-specific requirements.
• Affected Endpoints:
  • Create Card, request only
• Changes:
  • For BINs 527735, 555071, and 555243: card_limit is mandatory and must be ≥ 0.01.
  • For other BINs: card_limit is optional; if omitted, defaults to 0; if provided, must be ≥ 0, up to two decimal places, and cannot be negative.

Newtransaction_type values for account-level adjustments

• Added new types to support account-level adjustments in both API responses and reports.
• Affected Endpoints / Reports:
  • List Issuing Balances Transactions, response only: transaction_type field
  • Account Transaction Report: Transaction Type field
• Changes:
  • Added: FUNDS_TRANSFER_IN, FUNDS_TRANSFER_OUT, FEE_REFUND, FEE_DEDUCTION, MARGIN_PAYMENT, MARGIN_REFUND, OTHER.

Newtransaction_type values in Card transactions

• Added chargeback adjustment types for card-level transactions.
• Affected Endpoints:
  • Retrieve Cards Transaction, response only
  • List Cards Transactions, response only
• Changes:
  • Added: CHARGEBACK_DEBIT, CHARGEBACK_CREDIT.

New Webhooks

• Introduced two webhooks to notify chargeback postings on card transactions.
• Added Webhooks:
  • issuing.transaction.chargeback.credit: triggered when a chargeback credit is posted to a card transaction.
  • issuing.transaction.chargeback.debit: triggered when a chargeback debit is posted to a card transaction.

Banking

Adddeposit_reference to Deposit APIs and Webhooks

• Introduced deposit_reference to carry the customize reference.
• Affected Endpoints:
  • Retrieve Deposit, response only
  • List Deposits, response only
  • Webhooks: deposit.pending, deposit.compliance.rejected, deposit.completed
• Changes:
  • Add new string field deposit_reference to carry the customize reference.

Card Issuing

New Webhooks:card.update.succeeded & card.update.failed

• Two new webhooks are introduced to provide the final status of an Update Card operation:
  • card.update.succeeded: Triggered when the card order generated by Update Card reaches status SUCCESS.
  • card.update.failed: Triggered when the card order generated by Update Card reaches status FAILED.
• Documentation

Added New Response Fields:ending_balance and description

• Affected Endpoints:
  • List Issuing Balances Transactions, response only
• Change:
  • ending_balance: The balance after this transaction is completed.
  • description: A short description of the transaction.

Card Settlement Report Field Update

• Affected Report:
  • Card Settlement Report
• Change:
  • The Transaction Type field in the Card Settlement Report has been updated. The enum value ATM Withdraw has been renamed to Authorization.

Banking

Added New Response Field:purpose_code for some Payout APIs

• Affected Endpoints:
  • Retrieve Payout, response only
  • List Payouts, response only

The Check Beneficiary endpoint now supports PayNow recipients

• Affected Endpoints:
  • Check Beneficiary, request only
• Change:
  • A new request parameter additional_info.proxy_id can be provided with a PayNow proxy identifier to check if the beneficiary already exists and avoid duplicate creation.

Card Issuing

Card Settlement Report Field Update

• The Transaction Type field in the Card Settlement Report has been updated.
• The original type Purchase has been renamed to Authorization.

Account Center

New Optional Field:other_documents under representatives

• A new optional field other_documents is now supported under ownership_details.representatives to allow uploading POA or other supplemental documents.
• Affected Endpoints:
  • Create SubAccount (POST /v1/accounts/create_accounts) , request only
  • Retrieve Account (GET /v1/accounts/{id}) , response only
• Note: The field name differs between request and response:
  • Request uses doc_str
  • Response uses front

Create SubAccount request example:

"other_documents": [
  {
    "type": "PROOF_OF_ADDRESS" | "OTHERS",
    "doc_str": "base64 string or file ID"
  }
]

Retrieve Account response example:

"other_documents": [
  {
    "type": "PROOF_OF_ADDRESS" | "OTHERS",
    "front": "base64 string or file ID"
  }
]

Account Center

Added Create SubAccount Endpoint

• Documentation: Create SubAccount
• Endpoint: POST /api/v1/accounts/create_accounts
• Description:
  Enables creation of sub-accounts under the following business lines:
  • ACQUIRING
  • BANKING
  • ISSUING
• Both COMPANY and INDIVIDUAL entity types are supported.
• Sub-accounts created via this endpoint can still be queried via List Connected Accounts and Retrieve Account, with the response structure remaining unchanged.

Added Get Additional Documents Endpoint

• Documentation: Get Additional Documents

• Endpoint: GET /api/v1/accounts/get_additional

• Description:
  Used to retrieve the list of supporting documents required when creating COMPANY type sub-accounts using the Create SubAccount endpoint. The document types returned are based on the sub-account’s country and business code, and include:

  • Required documents (required_docs)
  • Optional documents (option_docs)

  The documents should be submitted via the additional_documents field in the Create SubAccount request.
  We recommend retrieving this list prior to initiating sub-account creation to ensure a smooth onboarding process.

Additional Notes

• Legacy Endpoint Compatibility:
  The legacy Create Account (POST /api/v1/accounts) endpoint remains available. If you’ve already integrated it, you may continue using it with no changes required.

• Query Endpoint Compatibility:
  Both List Connected Accounts and Retrieve Account support sub-accounts created by either Create Account or the new Create SubAccount endpoint. The response structure remains consistent, and no additional adaptation is needed.

• Recommendation:
  The legacy Create Account endpoint only supports sub-account creation under the BANKING business line. For new integrations or functional upgrades, we recommend using the Create SubAccount endpoint to benefit from broader business line coverage and improved structure.

Acquiring

Added acquiring.payment_intent.failed Webhook

• Trigger Condition: Triggered when a Payment Intent is automatically closed by the system upon reaching its expiry time.
• Note:
  • This event will not be triggered if the order is closed(cancelled) manually.
  • Please subscribe the event at Dashboard if you'd like to receive it.

Card Issuing

Updated Transaction Status Field

• Change: Added a new transaction status value PENDING to the transaction_status field.
• Affected Endpoints:
  • List Cards Transactions, response only
  • Retrieve Cards Transaction, response only

Banking

Added PayNow Support for Payout and Beneficiary APIs

Affected Endpoints:

• Create Payout (request only)
• Retrieve Payout (response only)
• Create Beneficiary (request only)
• List Beneficiaries (response only)
• Retrieve Beneficiary (response only)
• Update Beneficiary (request only)
• Check Beneficiary (request and response)

Changes:

• Added PayNow as a new enum value to the bank_details.clearing_system field.
• Added a new proxy_id field under additional_info. Supports UEN, phone number, or VPA.

Card Issuing

[backwards-incompatible]Enforced UUID Validation for Idempotency Key

Affected Endpoints:

• All POST endpoints (headers)

Changes:

• Enforced strict UUID format validation for x-idempotency-key in API requests headers.

2025-06-26

Added failure_code Field to PaymentAttempt

Affected Module:

• PaymentAttempt

Changes:

• Added a new failure_code field to the PaymentAttempt structure. This field indicates the reason for the payment attempt failure. For detailed error code definitions, refer to the Error Code Reference.payment_error section.

2025-06-18

• Renamed event_type from acquiring.payment.* to acquiring.payment_intent.*
• Added new event types:
  • acquiring.payout.created: triggered when a merchant initiates a payout request
  • acquiring.refund.created: triggered when a merchant initiates a refund request

2025-05-28

Updated Status Fields for Payment Objects

Affected Endpoints:

• Payment Intents related endpoints
• Payment Attempts related endpoints
• Payment Refunds related endpoints

Changes:

• Revised the enumerated values and definitions for the following fields:
  • intent_status
  • attempt_status
  • refund_status
    Refer to the corresponding API reference pages for the latest status enumerations.

Note:
This is a non-backward-compatible change.

Adjusted Supported payment_method Values

Affected Endpoints:

• Payment Intents related endpoints

Changes:

• Limited the supported payment_method types to the following:
  • card
  • card_present
  • alipaycn
  • alipayhk
  • unionpay
  • wechat
  
  All other payment method types are not supported yet.

2025-05-21

The first official release of the Acquiring API. This version provides a set of endpoints to support payment processing, including Payment Intents, Attempts, Refunds and webhook notifications.

2025-06-26

Added risk_controls Module to card.create.succeeded webhook

Affected Notification:

• webhook card.create.succeeded

Changes:

• Added a new risk_controls module to the notification payload. The returned values, such as 3ds and mcc, may vary depending on the card product.

2025-06-19

Added wallet_type field in card transaction APIs and reports

Affected endpoints:

• List Cards Transactions, response only
• Retrieve Cards Transaction, response only
• Webhook issuing.transaction.*

Affected report:

• Card Transactions Report
• Card Settlement Report

Changes:

• Added field wallet_type to identify the digital wallet used for the transaction (e.g., ApplePay, GooglePay).

2025-06-12

Added available balance in card-related webhook events.

Affected webhooks:

• card.create.*
• card.recharge.*
• card.withdraw.*

Changes:

• Added field card_available_balance to the webhook payloads of the above events. Indicates the card's available balance at the time of the event trigger.

2025-06-05

Card Product Currency Support

Affected endpoints:

• GET /api/v1/issuing/products, response only

Changes:

• Added card_currency to the response schema
  • Type: array of strings
  • Description: Specifies the currencies available for issuing cards with this product.
  • Example: ["SGD", "USD"]

2025-05-29

Card product response enhancements

Enhanced the response of List Card Products to include additional product-specific details.

Affected Endpoint:

• GET /api/v1/issuing/products, response only

Changes:

• Added card_form field to indicate the supported card form(s) for each product. Returns ["VIR", "PHY"] if physical cards are allowed; otherwise returns ["VIR"] only.
• Added max_card_quota field to specify the maximum number of cards that can be issued under the current account for the corresponding product.

The failure_reason field has been renamed to description.

Affected endpoints:

• GET /api/v1/issuing/transactions, response only
• GET /api/v1/issuing/transactions/{id}, response only
• Webhook: issuing.transaction.*

Changes:

• If transaction_status is DECLINED, this field contains the reason for the failure.
• If transaction_status is APPROVED, this field contains supplementary remarks.
  • For 3DS transactions where a fee is deducted from the card balance, this field displays the value 3DS Fee.

Note:
This is a non-backward-compatible change. And all transaction report files that previously included the failure_reason column have been updated to use description as the column header.

Simplified transaction_status in refund webhooks

Affected endpoints:

• Webhook: issuing.transaction.refund

Changes:

• Removed REFUNDED from the list of valid values for transaction_status
• transaction_status now only supports:
  • APPROVED
  • DECLINED
• For transactions previously returned as transaction_status: REFUNDED, the updated mapping is:
  • transaction_type: REFUND
  • transaction_status: APPROVED

Note:
This is a non-backward-compatible change.

Card status update: Added BLOCKED, Renamed INACTIVE

Affected endpoints:

• GET /api/v1/issuing/cards/{id}, response only
• GET /api/v1/issuing/cards, response only
• POST /api/v1/issuing/cards/{id}/status, request only
• Webhook: card.status.update.*

Changes:

• Renamed the card_status value INACTIVE to FROZEN in all relevant API responses and webhook payloads

  • FROZEN: Indicates the card has been temporarily disabled but can be reactivated by the customer

• Added a new card_status value BLOCKED to the card.status.update.* webhook payload

  • BLOCKED: Indicates the card has been administratively blocked by UQPAY. Unblocking requires a formal email request submitted to UQPAY.

Note:
This is a non-backward-compatible change.

2025-05-23

• This update introduces enhancements to the Card Management and Card Product modules. Key improvements include support for filtering cards by cardholder ID, exposure of NO-PIN payment limits, and returning configured NO-PIN amount ranges per card product.

Card Management

• A new request parameter cardholder_id has been added to the List Cards API to enable filtering based on the associated cardholder.

  Affected endpoints:

  • GET /api/v1/issuing/cards, request only

  Changes:

  • Added optional query parameter cardholder_id to support cardholder-level card listing.

• A new response field no_pin_payment_amount has been added to the Retrieve Card API to indicate the allowed amount for transactions without PIN verification. The value includes both amount and currency unit (e.g., 2000USD).

  Affected endpoints:

  • GET /api/v1/issuing/cards/{id}, response only

  Changes:

  • Added response field no_pin_payment_amount, formatted as <amount><currency>.

Card Product

• The List Card Products API now returns the configured NO-PIN payment amount limits per product. This array indicates the maximum allowable NO-PIN payment amount that can be configured for each currency supported by the card product.

  Affected endpoints:

  • GET /api/v1/issuing/products, response only

  Changes:

  • Added response field no_pin_payment_amount, an array of objects specifying the NO-PIN payment configuration limits.

2025-05-16

Added MCC Management Support to Risk Control Settings

Affected Endpoints:

• POST /api/v1/issuing/cards (Create Card)
• POST /api/v1/issuing/cards/{id} (Update Card)

Changes:

• Introduced two new optional fields in the risk_controls object:
  • allowed_mcc: Specifies a list of MCCs that are explicitly allowed. All other MCCs will be declined.
  • blocked_mcc: Specifies a list of MCCs that are blocked. All others will follow normal risk control evaluation.
• Only one of allowed_mcc or blocked_mcc can be set per card.
• MCCs must be provided as a JSON array of strings (e.g. ["5999", "6011"]). There is no limit on the number of MCCs included.

Note:
If neither allowed_mcc nor blocked_mcc is set, transactions will be evaluated using the default risk control logic.

2025-05-15

Added number_of_cards Field to Cardholder APIs

Affected Endpoints:

• GET /api/v1/issuing/cardholders (List Cardholders)
• GET /api/v1/issuing/cardholders/{id} (Retrieve Cardholder)

Changes:

• Added a new field to the response: number_of_cards

2025-05-14

Updated Validation Rules for x-on-behalf-of Header

Affected Endpoints:

• All endpoints supporting sub-account delegation via the x-on-behalf-of header

Changes:

• Enforced strict validation on the x-on-behalf-of header:
  • If provided, the value must be in valid UUID format.
  • The UUID must correspond to an existing sub-account.
  • If validation fails, the request will be rejected.

Note:
This change is not backward-compatible. Ensure your integration only sets x-on-behalf-of to a valid sub-account UUID, or omits it to operate under the master account.

2025-04-25

Updated Activate Card Endpoint

Affected Endpoint:

• POST /api/v1/issuing/cards/activate (Activate Card)
  • Added new required field: pin
  • Added new optional field: no_pin_payment_amout

Note:
This change is not backward-compatible due to the new required field (pin). Please ensure your integration is updated to avoid any request failures.

2025-04-18

Added Support for 3DS Control

Affected Endpoint:

• POST /api/v1/issuing/cards (Create Card)
• POST /api/v1/issuing/cards/{id} (Update Card)
  • Added new optional field: risk_controls

Note:
This change is backward-compatible and does not affect existing card behavior unless explicitly configured.

2025-04-15

Added Support for Cardholder Email

Affected Endpoint:

• POST /api/v1/issuing/cardholders/{id}(Update Cardholder)
  • Added new optional field: email

Note:

This change is backward-compatible and does not affect existing cardholders unless the email field is provided.

2025-06-26

Added Optional documentation Field to Payout API

Affected Endpoint:

• POST /api/v1/payouts, request only

Changes:

• Added an optional documentation field to the payout creation request. This field allows uploading supporting documents along with the payout request.

2025-06-12

Added support for POA file when creating account

Affected endpoints:

• POST /api/v1/accounts, request only

Changes:

• Added optional field other_documentation under the representatives array in request payload.
  • This field can be used to provide proof of address (PROOF_OF_ADDRESS) or other supporting documents during account creation.

2025-06-05

Beneficiary Schema Expansion

Affected endpoints:

• POST /api/v1/beneficiaries, request only
• GET /api/v1/beneficiaries/{id}, response only
• GET /api/v1/beneficiaries, response only
• POST /api/v1/beneficiaries/{id}, request only
• POST /api/v1/beneficiaries/check, not request, response only

Changes:

• Added additional_info.organization_code to beneficiary object (for company-type only)
  • Description: The Unified Social Credit Identifier assigned to the organization.
• This is a optional field
  

Payout Failure Reason Reporting

Affected endpoints:

• GET /api/v1/payouts/{id}, response only
• GET /api/v1/payouts, response only

Changes:

• Added failure_reason to payout response object.

2025-05-29

Removed SUBMISSION_FAILED from Payout Status Values

Affected Endpoints:

• POST /api/v1/payouts, response only
• GET /api/v1/payouts, request and response
• GET /api/v1/payouts/{id}, response only

Changes:

• Removed the SUBMISSION_FAILED status from the payout_status field.

Note:
This is a non-backward-compatible change.

2025-05-16

Added nationality and id_number Fields to Beneficiary

Affected Endpoints:

• POST /api/v1/beneficiaries (Create Beneficiary)
• POST /api/v1/beneficiaries/{id} (Update Beneficiary)
• GET /api/v1/beneficiaries/{id} (Retrieve Beneficiary)
• GET /api/v1/beneficiaries (List Beneficiaries)

Changes:

• Added a new required field: nationality
  • Two-letter country code representing the beneficiary’s nationality.
  • Note: This field is currently optional but will become mandatory after mid-June. Please ensure your integration includes this field to avoid future disruptions.
• Added a new conditional field for INDIVIDUAL type beneficiaries: id_number. Required only when all the following conditions are met:
  • The beneficiary is a Mainland China resident
  • bank_details.account_currency_code is CNH
  • payment_method is LOCAL

2025-04-17

Added Support for Retrieving Current Exchange Rates

New Endpoint:

• GET /api/v1/exchange/rates(Current Exchange Rates)

Note:

This is a reference-only endpoint. For rate-locking or quote-generation, use the Create Quote API instead.

2025-04-15

Added Support for Transaction-Type RFIs

Affected Webhook:

• Added new event type: rfi.transaction.action_required
  Enables RFI handling for deposit and payout scenarios. See Payout / Deposit RFI for more details.

Affected Endpoints:

• GET /api/v1/rfis/{id} (Retrieve RFI)
• POST /api/v1/rfis/answer (Answer RFI)
  → Added fields such as rfi_type, transaction_type, etc., to support transaction-related RFIs.

Note:
The original onboarding RFI flow (event_type = rfi.action_required) remains unchanged and fully backward-compatible.

2024-07-20

Features

• Added changelog.
• New deposit webhooks:
  • deposit.pending
  • deposit.compliance.rejected
  • deposit.completed
• New endpoints for deposit management:
  • GET /api/v1/deposit, get list of deposits.
  • GET /api/v1/deposit/{id}, retrieve a deposit by id.
  • POST /api/v1/simulation/desposit, simulate deposits into global account (sandbox environment).

Docs

• Corrected some descriptions and parameter restrictions.