Account Center

Supportbusiness_code in Account retrieval and listing

• Enable querying sub-accounts across Acquiring, Banking, and Card Issuing.
• Affected Endpoints:
  • Retrieve Account, request and response
  • List Connected Accounts, response only
• Changes:
  • Request (Retrieve Account only): Add optional business_code with enum values BANKING, ISSUING, ACQUIRING. If omitted, default to BANKING.
  • Response: Add business_code to indicate business line for both Retrieve and List.

Addemail_address for representatives in Create SubAccount

• Affected Endpoints:
  • Create SubAccount, request only
• Changes:
  • Request: Add optional fieldemail_address to ownership_details.representatives[].

Makewebsite_url and company_description optional in Create SubAccount

• Relax requiredness for business_details fields.
• Affected Endpoints:
  • Create SubAccount, request only
• Changes:
  • Request: Change business_details.website_url and business_details.company_description from required to optional.

Card Issuing

Simulate Authorization now supports card BIN40963608

• Added support to run authorization simulations in sandbox
• Affected Endpoints:
  • Simulate Authorization
• Changes:
  • No request/response schema changes.

Acquiring

New Payment Attempt webhook events

• Added new Payment Attempt (PA) webhooks to improve the timeliness of payment result notifications.

• Added Webhoooks:

  • acquiring.payment_attempt.created: triggered when PA status is INITIATED.
  • acquiring.payment_attempt.capture_requested: triggered when PA status is CAPTURE_REQUESTED. Receiving this event indicates the consumer has completed the payment, and the corresponding PI transitions to SUCCESS.
  • acquiring.payment_attempt.cancelled: triggered when PA status is CANCELLED.
  • acquiring.payment_attempt.failed: triggered when PA status is FAILED.
    • For one-to-one mapping (one PI contains only one PA): the corresponding PI can be considered failed as well (actually the PI itself transitions to FAILED after the system auto-close the PI).
    • For one-to-many mapping (one PI may include multiple PAs): the failure of one PA does not mean the PI has failed, and merchants can still initiate other PAs under the same PI.

• Doc link: https://docs.uqpay.com/reference/paymentattempt-result#/
  Note: To receive these notifications, please subscribe to the corresponding events in your Dashboard.

New Settlements API

• Introduced a new API to query settlement detail records that have been successfully settled.
• Added Endpoints:
  • Get list of settlements: GET /api/v2/payment/settlements
• Feature:
  • Supports optional parameters settlement_batch_id or payment_intent_id to query corresponding settlement records.
  • Supports pagination and time range filters.
  • Returns settlement detail records with settlement_status = success.
  • Refer to the Get list of settlements for full schema and examples.

Banking

[BREAKING]Added format restriction foraccount_number field

• Affected Endpoints:
  • Create Payout, request only
  • Create Beneficiary, request only
• Changes:
  • The bank_details.account_number field now only accepts alphanumeric characters (letters A–Z/a–z and digits 0–9).
  • Spaces, hyphens, and other special symbols are not allowed. If provided, the request will be rejected with a format error.
• Notes:
  • Applies to both INDIVIDUAL and COMPANY entity type beneficiaries.

Card Issuing

Addedupdate_reason field in Card APIs and Webhook

• Added a new field update_reason in both Card APIs and webhook events to indicate the reason for a card status change.
• Affected Endpoints:
  • List Cards, response only
  • Retrieve Card, response only
  • Update Card Status, response only
• Affected Webhooks:
  • card.status.update.*
• Changes:
  • New field update_reason is added to the API responses and webhook payload.

Card Recharge and Withdraw now support SHARE cards

• Affected Endpoints:
  • Card Recharge, request only
  • Card Withdraw, request only
• Changes:
  • SHARE cards now can adjust card_available_balance by
    • Card Recharge: increasing card_available_balance.
    • Card Withdraw: decreases card_available_balance.
• Notes:
  • For SINGLE cards: behavior remains unchanged.

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.