October 2026

2026.10.08

Compliance Update: Proof of Address Required for Red Market Nationalities

What changed?

In line with VISA Cross-Border Issuance requirements, the User Creation block on Visa-defined Red Market nationalities is replaced with a Proof of Address (POA) requirement. Users with a Red Market nationality can now be onboarded by supplying a POA at user creation. To comply with Visa requirements, the cardholder's POA must be issued from a non-Red Market jurisdiction. This is required for the cardholder to be eligible to receive and transact using the card.

The Country of Residence block on Visa-defined Red and Yellow markets and the StraitsX Compliance list remains in place. This change applies to nationality only.

Expected flow

1. Create User with a Red Market nationality now requires a POA document. Without it, the request is rejected and no user is created.
2. With a POA, the user is created and the POA is stored. Card creation proceeds as usual.
3. The POA may be reviewed later. If a resubmission or additional information is needed, you are notified by webhook and can resubmit via the Update User API, up to 3 attempts within a 360-hour (15-day) window per attempt. During a resubmission window, the user's existing cards continue to transact as usual, but new card creation is blocked.
   • If all resubmission attempts are rejected, the user is off-boarded and any existing cards and tokens are blocked or revoked.
   • If the resubmission is left unresolved, all cards under the customer are suspended by Compliance and cannot be reactivated by the customer. No new cards can be created, and the customer is not fully off-boarded in this state.
4. You are notified of the outcome by webhook:
   • Pending (user_kyc_pending) — Acknowledgement by our KYC system of the KYC details and POA submission.
   • Approved (user_kyc_approved) — The user becomes active and can create cards.
   • Rejected but retryable (user_kyc_resubmission_required) — The cardholder is expected to resubmit the POA via the Update User API, with the reason and attempts remaining included.
   • Customer off-boarded (customer_offboarded) — The user is off-boarded and no card can be created. Any existing cards and tokens are permanently blocked or deactivated.

Why this matters

With this update, you can:

• Onboard cardholders with a Red Market nationality who were previously blocked at user creation, by supplying a POA issued from a non-Red Market jurisdiction.
• Track a POA review to its outcome through webhook events, rather than discovering the result when card creation fails.
• Recover a retryable rejection through the Update User API instead of restarting onboarding.

General

This is a breaking change for integrations that onboard users with a Red Market nationality — Create User requests without a POA are rejected and no user is created.

What you need to do:

• Send a POA on Create User for Red Market nationality users. We accept a file download URL, which is downloaded and reviewed by our KYC system. The hosted file must be a valid .pdf, .png, .jpg, or .jpeg.
• Adopt the webhook events. This is mandatory — it is the only way to be notified of a review outcome. Exact event names and payloads will be published on the Webhook Event Types documentation page before the effective date.
• Support POA resubmission via the Update User API.

This feature goes live on production on October 8, 2026. Please begin testing on Sandbox from October 5, 2026, and not earlier.

Relevant documentation:

• Create User API
• Update User API
• Webhook Event Types
• Proof of Address (POA) and Identity Verification (ID&V)

2026.10.05

Product Update: New Payload Fields in Reconciliation Webhook Events

What changed?

Two new fields are added to our reconciliation webhook payloads to help you identify partial versus final clearing under a single authorization. These fields are added to both the reconciliation_success and reconciliation_manual_adjustment events.

Webhook payload fields:

• multiple_clearing_sequence_number (string) — Index of the current clearing (1, 2, 3 ...).
• multiple_clearing_sequence_count (string) — Total number of clearings expected under the authorization.

A clearing is the final one when multiple_clearing_sequence_number equals multiple_clearing_sequence_count.

Why this matters

With this update, you can:

• Identify the final clearing of an authorization without waiting for or inferring it from subsequent events.
• Distinguish a partial clearing from a completed one when reconciling a single authorization that settles across multiple clearings.
• Reconcile split-shipment and multi-capture transactions against your own records with the sequence context included in the payload.

General

This change is additive and backwards compatible. Existing fields are not affected, and no action is required if your integration ignores unrecognised fields. We recommend reviewing and updating your integration if you can benefit from these fields.

For more details, please refer to the following documentation:

• Multiple Clearing Sequence Guide
• Webhook Notification
• Webhook Event Types

2026.10.01

Compliance Update: Create User KYC Proof Requirement Becomes Mandatory

What changed?

To strengthen compliance with Visa's global card issuance requirements, all StraitsX Card Program Partners whose KYC proof requirement is currently set to OPTIONAL will be updated to MANDATORY.

This takes effect on October 1, 2026 at 18:00 SGT.

After the effective cut-off, all Create User requests submitted without a valid KYC proof will be rejected with the following error:

• XFC400069 — Kyc proof not provided

Why this matters

With this update, you can:

• Rely on a single, consistent KYC proof requirement across all card programs.
• Identify integrations that do not yet submit KYC proof ahead of the cut-off, rather than discovering the gap through rejected requests.
• Meet Visa's global card issuance requirements for cardholder verification.

General

This is a breaking change for integrations that do not currently submit KYC proof on Create User requests — those requests will be rejected after the cut-off.

Recommended action:

• If you already send KYC proof on every Create User request, no action is required.
• If you do not, please complete your integration before the cut-off.

Please review the updated documentation page for more details: Create User

September 2026

2026.09.24

Product Update: Create User API Additional KYC Fields (Global Issuance Program)

What changed?

This is a follow-up to the initial announcement: "New KYC fields for Create User API".

We are introducing the following changes to support more accurate KYC details:

• gender field (Mandatory from Sep 30, 2026)
  • New enum option available: OTHER.
  • Starting September 30, 2026, this field will become MANDATORY. This is a breaking change for integrations that do not currently send gender.
• registration_id_type field (Mandatory)
  • Two new enum options available: DRIVERS_LICENSE and RESIDENCE_PERMIT.
  • Validation for the registration_id field remains unchanged.

These new options and updated validations are now available. We recommend updating your integration if you can benefit from these changes.

Why this matters

With this update, you can:

• Submit a wider range of identity documents by using DRIVERS_LICENSE or RESIDENCE_PERMIT as the registration_id_type.
• Represent cardholders more accurately with the new OTHER option for gender.
• Align your integration with the Global Issuance Program KYC requirements ahead of the September 30, 2026 enforcement date.

General

The new enum options are additive and backwards compatible — existing values continue to work without changes.

gender becomes mandatory on September 30, 2026. Please ensure your integration populates this field before that date.

Please review the updated documentation page for more details: Create User

2026.09.21

Update: Rejection Reasons and Remote Host Authorization Error Codes

What changed?

To comply with Visa's mandate on Authorization Response Code usage, StraitsX has made adjustments to both our transaction rejection reasons and our Remote Host Authorization (RHA) error codes.

New and updated rejection reasons

• New rejection reasons have been added, for example BLOCKED_BY_CARDHOLDER and TRANSACTION_NOT_SUPPORTED_OR_BLOCKED_BY_ISSUER.
• Some rejection reason mappings have been updated. For example, a card-present-disabled decline now maps to BLOCKED_BY_CARDHOLDER instead of CARD_RESTRICTIONS.
• The documentation page has been updated with the latest rejection reasons and the definition of each. See Transaction Rejection Reasons.

New Remote Host Authorization error codes

• Eleven new RHA error codes have been added (CARD0007–CARD0017), allowing for more specific declines beyond the generic CARD0005 (Unauthorized) and CARD0006 (Card Restriction).
• There are no changes to the RHA request and response format.
• The documentation pages have been updated with the latest RHA error codes, including the use case and constraints of each. See Remote Host Authorization and Remote Host Authorization Error Codes.

Why this matters

With this update, you can:

• Return a more precise decline reason to your cardholders, instead of mapping several distinct scenarios onto a single generic code.
• Distinguish between decline causes when reconciling or investigating rejected transactions.
• Stay aligned with Visa's Authorization Response Code mandate and avoid potential issues with declined transactions being flagged.

General

If you consume transaction rejection reasons or response codes, please review your integration for the transaction webhook event (status == "rejected") and the Get Transaction Detail API. Rejection reason values that your integration does not recognise should be handled gracefully.

We recommend adopting the new RHA error codes for more accurate declines. Timely adoption keeps your programme aligned with Visa.

2026.09.11

New customer_offboarded Webhook Event

What changed?

Starting September 14th, 2026, StraitsX emits a new customer_offboarded webhook when a customer is offboarded on compliance grounds — a single customer-level signal that the relationship has ended, alongside the per-card and per-token webhooks you already receive.

When a customer is offboarded, all of the customer's cards are PERM_BLOCKed, all tokens are deactivated, and new card creation is rejected on every path (Create Card API, reissue, batch, unassigned-card assignment). Offboarding is irreversible.

Why this matters

You get one authoritative signal that a customer relationship has ended, instead of inferring it from multiple card blocks. Signature and delivery are identical to existing COP webhooks.

General

This event is opt-in per merchant and off by default. Contact your integration engineer to enable it for your program.

Updated documentation can be found here: Webhook Notification

2026.09.10

New idempotency_key Field in Remote Host Authorization Requests

What changed?

Starting Monday, September 28th, 2026, we're adding an idempotency_key field to the JSON body of every authorization request we send to your Remote Host endpoint.

• idempotency_key (string) — a unique identifier attached to each authorization request. If the same request is retried, it will carry the same idempotency_key, allowing you to detect and safely handle duplicates.

Why this matters

With this update, you can:

• Reliably detect duplicate authorization requests and avoid processing the same transaction more than once.
• Return the original result for a request you've already handled, instead of re-processing it.

General

This is an additive and backwards compatible change — no API changes are required on your end.

• If your endpoint already ignores unrecognized fields and you don't intend to use idempotency, no action is needed.
• If you want to adopt it: store the idempotency_key when you first handle a request, and if a request arrives with a key you've already seen, return the original result rather than processing it again.

Updated documentation: https://docs.straitsx.com/v1-CARDS/reference/remote-host-authorization

2026.09.03

Compliance Update: Red and Yellow Market Restrictions — Card Mailing Address

What changed?

In line with the VISA Audit and Compliance Global Cross-Border (XB) Issuance requirement, the existing Red and Yellow market restrictions have been extended to a card's mailing address. The mailing address country supplied for physical card delivery is now screened against the same market list already applied to user onboarding.

This screening applies to the mailing address / delivery country across the following endpoints:

• Create Card
• Update Card Printing Delivery Address
• Request Card for Printing
• Reissue Card
• Create Unassigned Card Batch Transfer

On a match, the card will not be created or delivered. No card record is created and no card is issued.

Why this matters

With this update, you can:

• Anticipate rejections at request time when a mailing address falls in a restricted market, instead of encountering a delivery failure later.
• Apply a single, consistent market list across both user onboarding and card delivery.
• Meet the VISA Global Cross-Border Issuance requirements for physical card fulfilment.

General

This is a breaking change for integrations that submit mailing addresses in restricted markets — affected requests are rejected and no card is issued.

These changes are compliance-driven and apply across all card programs. Existing cards and cardholders are not affected, but remain subject to future review.

For the list of Visa-defined Red and Yellow markets, please refer to the Red and Yellow Market Restrictions announcement for user onboarding, or contact your StraitsX representative.

August 2026

2026.08.27

Product Update: Automatic COF Token Deactivation on Repeated Insufficient Balance

Starting September 3rd, 2026, COF (Card-on-File) tokens will now be automatically deactivated after 2 (two) consecutive insufficient balance declines without any successful authorization in between.

• Applies to COF (Credential-on-File) tokens only. Other token types are unaffected.
• Token is deactivated after 2 (two) consecutive insufficient balance declines without any successful authorization in
  between.
• Deactivated tokens are permanent. They cannot be re-activated or updated to other statuses.
• A successful transaction of any type at any point resets the counter.
• When a token is deactivated, you will be notified via the CARD_TOKEN_STATUS_CHANGED webhook event.
• Cardholder can re-tokenize their card again, but they should be encouraged to top up their balance before doing so.

Why this matters

Such transaction adds to rejection rates and generates unnecessary retry traffic. Deactivating these tokens helps reduce noise for issuer, issuing groups, and the network.

General

This is a new mandatory validation. No API changes are required. Ensure your system handles the
CARD_TOKEN_STATUS_CHANGED webhook to receive notifications when a token is deactivated.

2026.08.20

Product Update: New KYC fields for Create User API

Added new fields to the Create User API to support enhanced KYC data collection:

• registration_id — National ID or passport number
• registration_id_type — Type of identification document
• gender — User's gender
• verification_result — KYC verification status
• residential_address — Object containing:
  • country — Country of residence
  • street — Street address
  • city — City name
  • state — State or province
  • postal_code — Postal/ZIP code

Why this matters

These fields enable merchants to submit comprehensive KYC information required for audit compliance. Collecting residential address and identification details upfront streamlines the user onboarding process and ensures regulatory requirements are met.

General

This change is additive and backwards compatible. All new fields are required for creating user. See the Create User API reference for accepted values and validation rules.

2026.08.20

Product Update: New Payload Fields in Transaction and Reconciliation Manual Adjustment Webhooks

What changed?

Starting on the effective date above, we're adding the following new fields to our webhook event payloads:

transaction event webhook payload fields:

• merchant_category_code
• transaction_channel
• is_3ds_transaction
• merchant_city
• merchant_country_code
• payment_token_type

reconciliation_manual_adjustment event webhook payload fields:

• merchant_city
• merchant_country_code

Why this matters

With this update, you can enrich your transaction processing logic with additional merchant and transaction context directly from the webhook payload, without needing to make separate
API calls.

General

This change is additive and backwards compatible. Existing fields won't be affected. Please check and update your integration.

Updated documentation can be found here: Webhook Notification

2026.08.11

Product Update: New Create User API Mandatory Field — Country of Residence

What changed?

As part of Visa's updated terms and conditions, we are introducing a new parameter in the Create User API: Country of Residence.

To facilitate a smooth transition, this field will initially be optional. However, in accordance with Visa's mandate for issuers, the Country of Residence field must be populated with the customer's accurate country of residence for all new user creations effective 11 August 2026.

Why this matters

We kindly request that you assess the impact on your systems and implement the necessary changes before the effective date to ensure continued compatibility with the Create User API and to avoid any disruptions.

General

Updated documentation can be found here: Create User.

2026.08.04

Product Update: Idempotency Support for Create Card Endpoint

What changed?

We're introducing support for an optional idempotency request header on the Create Card endpoint to prevent duplicate card creation during network retries.

Include an Idempotency-Key header in your Create Card request. If the same key is sent again within 24 hours, the endpoint will return the original response instead of creating a new card.

Behavior:

• If the original request succeeded (2xx) or failed with a client error (4xx), the stored response is replayed on retry
• If the original request is still in-flight, a duplicate request returns 409 Conflict
• If the original request failed with a server error (5xx), the key is released so you can retry
• Replayed responses include an Idempotency-Replayed: true header

Key details:

• The key must be 256 characters or fewer
• Keys expire after 24 hours

Why this matters

With this update, you can safely retry Create Card requests without risk of duplicate card creation during network issues, enabling more resilient integrations with built-in duplicate detection.

General

This change is additive and backwards compatible. Requests without the Idempotency-Key header will behave exactly as before.

Updated documentation can be found here: Create Card.

2026.08.03

Product Update: Just-in-Time Funding Recommendation Webhook

What changed?

A new webhook event type just_in_time_funding_recommendation is now available to support Just-in-Time Funding. Every day, at 6PM SGT at the earliest, StraitsX
will send up to two just_in_time_funding_recommendation webhook events. One for each settlement type: DOMESTIC, and INTERNATIONAL. Please ensure the recommended amount is topped up by our agreed daily funding cut-off.

Webhook payload fields:

• event_type — just_in_time_funding_recommendation
• current_spend (string) — Total amount spent for this settlement type on the calculation date
• recommended_top_up (string) — The amount to top up to cover that spend
• currency (string) — Currency of the amounts. Reported in USD.
• settlement_type — DOMESTIC or INTERNATIONAL
• calculation_date — The date the spend was calculated for
• idempotency_key — Unique key per event

Why this matters

With this update, you can:

• Receive daily proactive funding recommendations to ensure your settlement account has sufficient balance
• Plan top-ups ahead of Visa settlement based on actual cardholder spend data
• Reduce the risk of settlement shortfalls by acting on timely recommendations

General

Please note: the recommended amount is an estimate, not the actual settlement figure from Visa. It is calculated from your cardholders' observed spend, and Visa's actual settlement may be higher or lower than this amount. Treat it as guidance for topping up your settlement balance — not as the final settled amount.

Updated documentation can be found here: Webhook Notification

July 2026

2026.07.20

Product Update: Card Status Transition & Card PIN Actions Webhook Event

Four new webhook event types to help you stay informed about card lifecycle changes in real-time.

What changed?

• New event card_status_transition — fired whenever a card's status changes (e.g. INACTIVE → ACTIVE, ACTIVE → SUSPENDED).
• New events card_pin_set, card_pin_changed, card_pin_reset — fired when a cardholder sets, changes, or resets their PIN.

Why this matters

With these events, you can:

• Track card activation and suspension in real-time without polling
• Monitor PIN lifecycle events for compliance or notification workflows

General

These new webhook events are opt-in. To enable, contact an integration engineer and we'll activate it for you. Events will be delivered to your existing webhook endpoint. No additional configuration needed.

Updated documentation can be found here: Webhook Notification

June 2026

2026.06.23

Product Update: Custom Per-Transaction Limit — Trusted Program Intent Values

New intent values are now available for the Create Custom Per-Transaction Limit API, enabling trusted card programs to specify the reason for elevated spending.

What changed?

The following intent enum values have been added:

• ACCREDITED_INVESTOR — For accredited investor transactions
• VIP — For VIP cardholders
• VVIP — For VVIP cardholders
• TRUSTED_CUSTOMER — For trusted customer transactions

These values are only available for trusted card programs. Please contact our team to enable.

Why this matters

With this update, trusted card programs can:

• Specify a more granular reason when requesting temporary elevated per-transaction limits
• Better categorize high-value cardholder spending scenarios

General

This change is additive and backwards compatible. Existing intent values (INTERNATIONAL_TRAVEL, HIGH_VALUE_PURCHASE,MEDICAL_OR_EMERGENCY, BUSINESS_EXPENSES, EVENT_OR_SPECIAL_OCCASION) remain available to all programs.
Maximum amounts: USD 80,000.00 / SGD 100,000.00

2026.06.16

Product Update: Dispute Financial Advice Webhook Event

What changed?

A new webhook event type dispute_financial_advice will be delivered when a transaction-level dispute financial record is received via the Visa clearing system.

Webhook payload fields:

• event_type — dispute_financial_advice
• card_opaque_id — The opaque ID of the affected card
• card_number_opaque_id — The opaque ID of the card number
• acquirer_reference_number — The ARN for the transaction
• authorization_code — The authorization code of the original transaction
• transaction_identifier — Visa transaction identifier
• dispute_financial_reason_code — Reason for the dispute (e.g. "FRAUD", "CONSUMER_DISPUTE")
• dispute_status — Current status of the dispute
• rate_table_id — Rate table used for currency conversion
• settlement_type — Type of settlement
• settlement_amount_type — Direction of settlement (CREDIT/DEBIT)
• purchase_date — Original purchase date
• central_processing_date — Visa's central processing date
• merchant_name — Merchant name
• merchant_city — Merchant city
• merchant_country — Merchant country code
• mcc — Merchant Category Code

Why this matters

With this update, you can:

• Receive immediate notification when a dispute financial record clears via Visa
• Identify the affected card, disputed amount, and whether the outcome is a credit (win) or debit (loss)
• Automate reconciliation using the exposed dispute financial advice records

General

This is a brand-new webhook event, meaning zero impact on your existing integrations. To maintain total operational control, this feature is opt-in. When you are ready to start receiving these events for your program, please reach out to the integration team, and we will activate it for you.

Updated documentation can be found here: Webhook Notification

May 2026

2026.05.28

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

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_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.18

Update on Create Custom Per-Transaction Limit API Endpoint

The maximum duration_in_days for the Create Custom Per-Transaction Limit API has been increased from 7 to 14 days, allowing more flexibility for use cases like international travel or extended business trips.

Updated documentation: Create Custom Per-Transaction Limit

2026.05.15

List OCT Sender Entries

A new API endpoint that allows issuing groups to view OCT sender entries associated with their cards. Supports filtering by status, card, and encrypted sender name, with cursor-based pagination.

Updated documentation: List OCT Sender Entries

Whitelist OCT Sender Entry

A new API endpoint that allows issuing groups to whitelist a previously flagged OCT sender entry. Once whitelisted, the sender will no longer be flagged in future OCTs. Requires the entry's opaque_id and a reason for whitelisting.

Updated documentation: Whitelist OCT Sender Entry

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

• 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 Conflict with code XFC409001 error 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 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.