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_type—card_custom_per_transaction_limit_revokedidempotency_key— Key used to keep the request idempotentcard_opaque_id— The opaque ID of the affected contractlimit_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 deviceHIGH_RISK_DEVICE_PROVISIONING— The provisioning request is flagged as high risk by the wallet providerMULTIPLE_DECLINED_REASON_CODES— Multiple wallet provider risk reason codes triggered a declineAPPLE_PAY_SECURE_ELEMENT_NOT_SUPPORTED— Apple Pay Secure Element provisioning is not supportedMAXIMUM_TOKENS_REACHED— The maximum number of provisioned tokens for this card has been reachedTOO_MANY_PROVISIONING_ATTEMPTS— Provisioning attempts exceeded the hourly rate limitVISA_TOKEN_RISK_SCORE_TOO_HIGH— Visa token risk score exceeded the rejection thresholdCONSECUTIVE_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 aboveUNKNOWN— 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 transactioncavv_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
acquirer_reference_number Field for Reconciliation Webhook EventsA new acquirer_reference_number field has been added to the following webhook events:
reconciliation_successreconciliation_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
BLOCKED_BY_FRAUD from Update Card Status APIThe 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
- Create Spend Limit endpoint https://docs.straitsx.com/v1-CARDS/reference/create-spend-limit : Added validation to prevent updating existing spend limits. The endpoint now returns a
409 Resource Conflictwith codeXFC409001error when attempting to create a spend limit that already exists.
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 Conflictresponses 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_summaryWebhook now includes thetotal_atm_declinefield when applicable.- New
settlement_offsetwebhook 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.
Updated about 2 hours ago
