Issuing

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.