Release Notes

May 2026

2026.05.28

Product Update: Card Custom Per-Transaction Limit Revoked Webhook Event

A new webhook event type card_custom_per_transaction_limit_revoked will be delivered when a card's custom per-transaction limit is revoked.

What changed?

A new webhook event type card_custom_per_transaction_limit_revoked will be delivered when a card's custom per-transaction limit is revoked.

Webhook payload fields:

  • event_typecard_custom_per_transaction_limit_revoked
  • idempotency_key — Key used to keep the request idempotent
  • card_opaque_id — The opaque ID of the affected contract
  • limit_amount — The revoked limit amount (e.g. "50000.00")
  • currency — The currency of the limit (e.g. "SGD")
  • revoke_reason — The reason provided for revoking the limit

Why this matters

With this update, you can:

  • Receive immediate notification when a custom per-transaction limit is revoked
  • Identify which contract was affected and the revocation reason
  • Update downstream systems or dashboards automatically in response to limit changes

General

This is a new webhook event — no existing integrations are affected. To receive this event, ensure your webhook endpoint is configured to accept the new event type.

Updated documentation can be found here: Webhook Notification


2026.05.13

Token Provisioning Failed Webhook Enhancement

The failed_provision_reason field has been enhanced with more specific rejection reasons and expanded coverage for previously unreported failure scenarios.

New failed_provision_reason values added:

  • KNOWN_FRAUD_DEVICE — The wallet provider device score indicates a known fraud device
  • HIGH_RISK_DEVICE_PROVISIONING — The provisioning request is flagged as high risk by the wallet provider
  • MULTIPLE_DECLINED_REASON_CODES — Multiple wallet provider risk reason codes triggered a decline
  • APPLE_PAY_SECURE_ELEMENT_NOT_SUPPORTED — Apple Pay Secure Element provisioning is not supported
  • MAXIMUM_TOKENS_REACHED — The maximum number of provisioned tokens for this card has been reached
  • TOO_MANY_PROVISIONING_ATTEMPTS — Provisioning attempts exceeded the hourly rate limit
  • VISA_TOKEN_RISK_SCORE_TOO_HIGH — Visa token risk score exceeded the rejection threshold
  • CONSECUTIVE_CVV_FAILURES — Card blocked due to consecutive CVV verification failures

The following previously used reason values have been removed:

  • SUSPECTED_FRAUD — Superseded by more specific reasons provided above
  • UNKNOWN — No longer used
  • This is a breaking change for issuing groups currently parsing failed_provision_reason == "SUSPECTED_FRAUD" or "UNKNOWN". Please update your integration to handle the new reason
    values before the release date.

Updated documentation can be found here: Webhook Notification


2026.05.09

Create Custom Per-Transaction Limit

Effective May 9, 2026 at 00:00 SGT (UTC+8), the current elevated per-transaction limit of SGD 100,000 / USD 80,000 will be removed. All issuing groups will default to SGD 20,000 / USD 16,000 per transaction. Any existing manually requested limits will also be removed. This change is required to comply with Anti-Money Laundering (AML) requirements.

A new Create Custom Per-Transaction Limit API endpoint is now available for issuing groups that require temporary elevated limits:

  • Up to SGD 100,000 or USD 80,000 per transaction
  • Duration of up to 7 days from activation
  • Requires a valid intent/reason
  • This is a breaking change for issuing groups currently relying on the elevated SGD 100,000 / USD 80,000 default. Please review your integration and adopt the Custom Per-Transaction
    Limit API if elevated limits are required.

Updated documentation can be found here: Create Custom Per-Transaction Limit


List Custom Per-Transaction Limit

A new List Custom Per-Transaction Limits API endpoint allows issuing groups to view their cardholders' custom per-transaction limits. Filters include active, inactive (scheduled or expired), and revoked entries.

Updated documentation can be found here: List Custom Per-Transaction Limits



2026.05.05

New 3DS Authentication Fields in Remote Host Authorization Metadata

Two new fields have been added to the metadata section of Remote Host Authorization (RHA) calls:

  • electronic_commerce_indicator — Visa ECI value indicating the 3DS authentication outcome of the transaction
  • cavv_result_code — Result of CAVV (Cardholder Authentication Verification Value) validation by the issuer

These fields provide improved risk handling and issuer verification visibility for 3DS-authenticated transactions.

This change is additive and backwards compatible. Review your integration to ensure the new fields do not affect existing processing logic.

Updated documentation can be found here: Remote Host Authorization


New acquirer_reference_number Field for Reconciliation Webhook Events

A new acquirer_reference_number field has been added to the following webhook events:

  • reconciliation_success
  • reconciliation_manual_adjustment

An Acquirer Reference Number (ARN) is a unique 23-digit identification number assigned by the acquirer to each Visa clearing transaction. ARN is used to track and trace transactions through Visa's system, especially for reconciliation purposes.

This change is additive and backwards compatible. Review your integration to ensure the new field does not affect existing processing logic.

Updated documentation can be found here: Webhook Notification



April 2026

2026.04.29

Update: Removal of BLOCKED_BY_FRAUD from Update Card Status API

The BLOCKED_BY_FRAUD status will no longer be accepted in the Update Card Status API request and will be reserved for internal use only.

Please note that BLOCKED_BY_FRAUD remains a valid enum value and may still appear in API responses. However, it can no longer be used when sending requests.

Moving forward, please use one of the following statuses when updating card status:
ACTIVE, SUSPENDED, LOST, STOLEN, PERM_BLOCK, INACTIVE

Key Details:
Endpoint: PUT/api/v1/issuing_plans/{issuing_plan_opaque_id}/users/{customer_opaque_id}/cards/{contract_opaque_id}/status
Change: BLOCKED_BY_FRAUD removed from accepted request values


March 2026

2026.03.05

Improvement: Transaction List API Enhancement

We are pleased to announce a performance improvement to the GET /transactions endpoint to ensure faster and more reliable responses.

The Transaction List API now includes a timeout to improve overall system stability and response times. Queries that take longer than 10 seconds will return an HTTP 504 response with error code XFC504001 instead of hanging indefinitely.

Key Details: Endpoint: GET /transactions Timeout: 10 seconds per request Error Response: If a query exceeds the timeout, you will receive an HTTP 504 with error code XFC504001 and message Query timeout exceeded

Recommended Actions: If you experience timeout errors, consider narrowing your query by using filters such as start_date, end_date, or reducing the page_size. This will help ensure your requests complete within the allowed duration.


February 2026

Create Limit API Behavior Change

Changed

Migration Guide

  • If you were previously using the Create Spend Limit API to update existing limits, you must now use the dedicated Update Spend Limit endpoint instead.
  • Check for Resource Conflict responses and handle them appropriately in your integration.
  • To update an existing spend limit, use https://docs.straitsx.com/v1-CARDS/reference/update-spend-limit instead.

January 2026


December 2025

2025.12.24

Card Management and Transaction

  • To enhance flexibility and better support different acquirer PIN flows, we now support both 4-digit and 6-digit PINs.

Note

Action required (Non-PCI merchants):

If you want to support 4-digit PINs, please update your PIN setup / PIN change input template to use a 4-digit PIN pad when users set or update their PIN.

PCI-compliant merchants: You may encrypt and submit a 4-digit PIN directly via our PIN setup or PIN reset APIs. No changes are required if you continue using 6-digit PINs.

2025.12.22

Card Management

  • Added List Merchant BIN endpoint to view all available BINs and associated card products for your issuing group.
    • Merchant BIN indicates the starting and end range of your card program
  • Added a Create Card Product endpoint to create new card products with custom embossing file name prefixes for physical card designs.
  • Enhanced Card Configuration Update endpoint to allow updating card product designs before printing, as well as modifying the embossing name.

Note

  • Card design changes and embossing name are only permitted before a card is scheduled for printing. New card product can reuse the same merchant bin.
  • API documentation will be updated following deployment.

2025.12.15

Remote Host Authorization

  • CVV2 verification results are now included in the metadata section of RHA calls for improved risk handling and issuer verification visibility.

Settlement

  • settlement_summary Webhook now includes the total_atm_decline field when applicable.
  • New settlement_offset webhook event has been added to notify you whenever a settlement offset occurs, allowing for improved tracking of credits and debits.

General

  • All changes are additive and backwards compatible. Review your integration to ensure new fields and webhooks do not affect existing processing logic.