Last updated: 2026-03-27

2026-01-21

This release relates to Smart Retry.

Smart Retry now supports configurable decline-code selection, with a curated default list and a clearer UI label — without impacting UI responsiveness.

Key highlights

Curated default list: A predefined set of commonly retriable decline codes is now available for quick selection.
Manual flexibility: Merchants can add or remove decline codes to support advanced use cases.
Clearer label: Updated to "Select codes to retry failed transactions" for improved clarity.

2026-01-19

This release relates to tokenisation.

We have updated omni-token management to support network-token provisioning for existing omni-tokens, even if no transaction has taken place yet (as long as the underlying card is still valid). This helps keep omni-tokens usable across eCommerce and in-store channels and reduces disruption risk when cards expire.

Endpoint: /v1/omnitokens/{id}/provisionNetworkToken

2026-01-14 - Tokenisation

Smart Payments Platform now auto-refreshes network tokens in Token Vault whenever a token returns to ACTIVE after being SUSPENDED (for example, following expiration or a token reissue/change). Updated DPAN network tokens are made available immediately for Merchant-Initiated Transactions (MITs) so subsequent payments can continue seamlessly and without manual updates.

This release relates to tokenisation.

Cryptogram handling is now fully optimized for Omni Token customers using network tokens with our next-generation Token Vault. For Customer-Initiated Transactions (CIT), we always send the DPAN plus a cryptogram. For Merchant-Initiated Transactions (MIT), we use the DPAN only when it's available to avoid unnecessary cryptogram requests.

If the DPAN is missing, we automatically retrieve both the DPAN and a cryptogram to ensure compliance and seamless processing.

This enhancement applies only to Omni Token customers. Customers using registration and network tokens are already optimized and remain unchanged.

2026-01-14 - MAC Control

We've enhanced MAC Control to give merchants greater flexibility in how retry decisions are applied for selected MAC codes (for example, MAC02, MAC21, MAC24–MAC30). Merchants can choose between two matching modes to align with their business flows, including scenarios where order IDs may change between attempts:

Strict match (default): Blocks retries only when account, amount, currency, and merchant transaction ID all match.
Moderate match: Blocks retries when account, amount, and currency match, even if the merchant transaction ID changes.

This helps merchants adapt retry logic when order IDs change between attempts without weakening protection. Existing configurations remain unchanged; Strict match remains the default unless you request Moderate match.

Availability: This capability is part of MAC Control and can be enabled upon commercial agreement.

We continue to update MAC Control to make retry handling more transparent and easier to troubleshoot.

What's new

When a retry is blocked due to issuer guidance (for example, "retry after 72 hours" or "do not retry"), the payment artifacts now include the original transaction ID that triggered the rule — so you can see why the retry was blocked and which transaction caused it.

Where you'll see it

The original reference is surfaced in the payment response, payment query, and webhook payload under processingDetails.macControl.originalTxId.

Why it matters

End-to-end traceability lets you quickly connect a blocked retry to the originating attempt, accelerate debugging, and provide clearer explanations in merchant support cases.

Timing clarity

We've also added an optional retryAfterMinutes field. When a MAC includes a delay (for example, "retry after 10 days"), this field shows exactly how much time remains before a retry may be accepted — reducing premature attempts and confusion.

Data fields at a glance

processingDetails.macControl.originalTxId — the transaction ID that triggered the MAC Control rule.
retryAfterMinutes (optional) — remaining minutes until a retry may be accepted when issuer guidance includes a delay.

Compatibility and rollout

Fully backward-compatible and works seamlessly with network tokens, omni tokens, smart retries, SCA, and account updater.

Learn more in the MAC Control section and see implementation details in the MAC Guide.

We continue to optimize MAC Control for speed and efficiency. Retry-decision data is now retained only as long as necessary to support matching of declined transactions during retry handling.

Key highlights

Automatic expiry: MAC-related data is removed once its validity period ends.
Accurate matching, optimal performance: Keeps retry-decision logic accurate while minimizing storage and lookup overhead.
No action required: This process runs automatically — no configuration changes for merchants.

Availability: This capability is part of MAC Control and can be enabled upon commercial agreement.

We continue to expand MAC Control for clearer monitoring and reporting. Now, MAC Control returns dedicated decline codes when retry attempts are blocked based on MAC — so you can quickly see why a retry was prevented and what to do next.

Result codes grouped by recommendation

Retry after delay (700.600.xxx) – indicates when you can safely retry (for example, MAC02 - 72 hours, MAC24 - 1 hour).
Do not retry (700.601.xxx) – indicates retries should not be attempted (for example, MAC03 - account closed or fraud suspected).

Additional details

Status code: 76 (Rejected MAC) with detailed reason codes for clarity.
No MAC match: If no MAC match is found, MAC Control logs the evaluation but does not create a transaction.

Availability: This capability is part of MAC Control and can be enabled upon commercial agreement.

2025-10-16

This release relates to MAC Control.

Peach Payments has improved MAC Control to ensure more accurate handling of declined transactions. The system now leverages additional transaction attributes to determine whether a retry should be blocked or allowed based on Merchant Advice Codes (MAC).

Key highlights

More precise matching for retry decisions using attributes such as:
- Account details
- Merchant transaction ID
- Amount and currency
- MAC code
- Expiry date
- Merchant ID
Supports compliance with issuer and scheme rules by preventing retries where not recommended.
Enhanced visibility for you through improved logging and actionable insights.

Availability: This capability is part of the MAC Control product and requires a commercial agreement.

2025-10-13

This release relates to Fraud Management.

Peach Payments has enhanced the Merchant Fraud Integration to include additional iovation fields in the Risk Scan response when available from Fraud Scans. These fields provide deeper insights into device and browser characteristics, improving fraud detection and risk assessment.

New iovation fields

IOVBRWSRTYPE – Browser Name
IOVBRWSRVRSN – Browser Version
IOVDEVICEFIRSTSEEN – Date/time device was first seen by iovation
IOVFLSHINSTALLED – Whether Flash is installed
IOVDEVICENEW – Whether the device is new to iovation
IOVDEVICETZ – Device TimeZone
IOVIPADDRCITY – City associated with the Real IP address
IOVIPADDRREGION – State/region of the Real IP address
IOVREALIPSRC – Source of the Real IP address

2025-10-10

This release relates to MAC Control.

Peach Payments has introduced Merchant Advice Code (MAC) support as part of the new MAC Control product. MAC codes indicate whether a declined authorisation should be retried or not. With MAC Control, retry attempts for transactions declined with specific MAC codes are automatically blocked, helping you avoid unnecessary fees and improve compliance with issuer and scheme rules.

Key highlights

Automatic blocking of retries for declined authorisations where retrying is not recommended (e.g., MAC01, MAC03, MAC21, MAC22, MAC02, MAC24–30). Blocking applies when retry conditions match original transaction details and MAC expiry is valid.
Detailed logs are available for troubleshooting and audit purposes.

Learn about MAC and their meanings by visiting the MAC Control integration guide.

Availability: This capability is part of the MAC Control product and requires a commercial agreement.

2025-10-06

This release relates to tokenisation and COPYandPAY.

Peach Payments is pleased to announce the latest update to the COPYandPAY widget, now supporting the new version of omni tokens, including network tokenisation support.

Key improvements

Network tokenisation support: The new omni tokens version now includes network tokenisation, delivering higher authorisation rates and better incentives through compliance with network rules.
Merchant onboarding requirement: You must first onboard with card networks before network tokens can be used in payments, ensuring a seamless and secure transaction process.
Enhanced payment visibility: All payments made with omni tokens are now visible in the Payment Orchestration Platform, providing improved tracking and management of transactions.
Improved authorisation process: Network token transaction data is leveraged to authorise payments, increasing efficiency and success rates.

This update empowers omnichannel customers to fully leverage network tokenisation, resulting in more efficient and successful transactions.

2025-09-25

This release relates to tokenisation.

Cards stored as PAN tokens that have not been used for payments are at risk of expiring without a network token being provisioned. Once expired, schemes block tokenisation as a fraud prevention measure — resulting in lost tokens and disrupted shopper experiences.

To address this, Peach Payments has introduced a new standalone API endpoint that allows you to provision a network token for an existing registration, even if no payment has occurred — as long as the card is still valid.

This proactive approach helps secure network tokens in advance and ensures stored credentials remain usable.

New endpoint

POST /v1/registrations/{uuid}/provisionNetworkToken

Use this endpoint to trigger network token provisioning for a registered card before it expires.

2025-09-02

This release relates to tokenisation.

If you use the new omni token solution, you can now leverage automatic network token provisioning when switching to network tokens.

What's new

When you enable network token usage, the system automatically attempts to provision a network token for existing omni tokens during regular payment flows.
Provisioning is triggered dynamically before authorisation, with activation handled by the issuer.
Once available, the network token is used in future transactions — no changes required to your integration.

2025-08-20

This release relates to tokenisation.

You can now perform zero-amount account verification using network tokens you provide — leveraging the tokenAccount.* API parameters. This enables validation of card credentials without initiating a payment.

Please note that this feature depends on the capabilities of the acquirer you are routing the transaction to, not all acquirers currently support zero-amount verification using network tokens.

What's new

Zero-amount verification using network token data you control.
New API support via tokenAccount.* parameters in transaction requests.
Routing compatibility with acquirers that support network tokens.

2025-08-11

This release relates to COPYandPAY and Tokenization.

Peach Payments has enhanced the one-click checkout experience in COPYandPAY!

Shoppers using network tokens will now see up-to-date card details — such as the latest last four digits and expiry date — automatically reflected in the widget.

What's new

Live card updates: Updated card details are now displayed automatically when changes are received from the schemes via network tokens.
Improved shopper experience: Reduce friction and confusion at checkout with accurate, real-time card information.
Seamless integration: No additional integration required if you are already using COPYandPAY with network tokens.

This update helps you deliver a smoother, more transparent one-click checkout — boosting shopper trust and conversion rates.

2025-07-03

This release relates to tokenisation.

In line with Peach Payments' commitment to delivering seamless and efficient checkout experiences, support for one-click checkout using stored omniTokens is now available.

Main features

Convenient checkout: You can now enable one-click checkout by leveraging stored omniTokens. This utilises Peach Payments' Token Vault capabilities to detokenise omniTokens and retrieve card details for payment finalisation.
Enhanced system visibility: The new omniToken flow introduces greater transparency within the system.
- Detokenisation of PAN: When a network token is not available, detokenisation requests are processed with paymentType=DT.
- Network token fetch: When the network token route is enabled, detokenisation requests are processed with paymentType=TF.

2025-06-16

This release relates to tokenisation.

To further enhance transparency and efficiency, Peach Payments is introducing a new result code for declined transactions involving deleted network tokens.

When a token is removed by the issuer—due to card expiration, account closure, or a cardholder request—you will now receive the following result code:

800.100.328 – "Network token transaction declined (deleted network token)."

This update helps you identify and manage token-related declines with greater clarity.

2025-06-16

This release relates to tokenisation.

In line with Peach Payments' commitment to transparency and efficiency, a powerful enhancement is now available: you will now receive updated card details directly through the network token route.

Whenever a shopper's card information changes, like a new expiry date or updated last four digits, issuers will push these updates through the schemes, ensuring you always have the most current data.

New card details format:

{
  "newCard": {
    "last4Digits": "0003",
    "expiryMonth": "04",
    "expiryYear": "2027"
  }
}

Token life cycle events: Life cycle events for network tokens are now exposed. This means you'll be notified of key updates, such as card reissues or expiry changes, so you can keep your shoppers informed and maintain seamless payment experiences.

2025-05-15

This release relates to tokenisation.

Peach Payments introduces enhanced support for threeDSecure. parameters in the OmniToken solution when using an external 3-D Secure version 2 authentication provider (MPI).

New functionality

3-D Secure v2 with External MPIs: You can now include threeDSecure. parameters in:
- POST /v1/payments with createOmniToken=true
- POST /v1/omnitokens/{omnitoken}/payments

Why it matters

OmniTokens are widely used across eCommerce and in-store channels—especially in the U.S., where loyalty programmes often rely on shared tokens. As digital commerce and fraud risks grow, adoption of 3-D Secure version 2 is increasing. This update enables secure integration with external MPIs, helping you stay ahead.

Behaviour changes

Before: threeDSecure. parameters were ignored.
Now: Fully supported for secure CIT payments and standalone tokenisations with shopper present.

2025-05-05

This release relates to tokenisation.

In line with Peach Payments' commitment to staying ahead of industry trends, starting with version 61, the Mastercard Payment Gateway Services (MPGS) integration now supports Network Token (NT)–based payment authorisation.

This enhancement enables you to authorise transactions using network token data, aligning with the latest scheme requirements. Key benefits include:

Lower interchange costs
Higher approval rates
Enhanced security, as issuers pre-approve token provisioning

This update helps you remain compliant whilst boosting performance and improving the overall customer experience.

2025-04-24

This release relates to tokenisation.

Following the major enhancement to omni token management on October 23, 2024, the COPYandPAY widget now fully supports the new omni token flow.

With this update, you can securely collect card details from shoppers via the widget, tokenise the card using the Token Vault, and initiate a paymentType=TK transaction.

Tokens can be created

As standalone tokens
During an initial purchase
As part of account verification

This enhancement empowers you to take full advantage of network tokenisation, resulting in more efficient, secure, and successful transactions.

2025-04-10

This release relates to Single Sign On.

Peach Payments is pleased to announce further enhancements to the Single Sign-On (SSO) system, focusing on improved token management and user authentication.

Key updates

Inclusion of id_token in token response: For customers using the SSO integration, the id_token will now be included in the token response. This token contains user information, allowing integrators to obtain details directly without needing to call the /userinfo endpoint.
Enhanced token management: The refresh_token parameter is now documented, allowing applications to obtain new access tokens without requiring users to re-authenticate. This ensures continuous access and improves user experience.

2025-03-05

This release relates to tokenisation.

In alignment with Visa and Mastercard's ambition to process every single digital payment transaction with a network token, Peach Payments is pleased to announce support for network tokens in one-time payments.

Main features

Immediate network token provisioning: Network token provisioning is attempted immediately for one-time payments.
3-D Secure flow and payment with network token: If the network token is active, 3-D Secure checks and payment are performed using the network token.
Fraud screening with real PAN: Fraud screening is conducted using the real PAN to leverage consortium data.
Support for COF payments via standalone endpoint: Customers storing card data in a PCI DSS-compliant environment can now use the /v1/payments standalone endpoint to send COF payments - flagged as either CIT (Cardholder-Initiated Transaction) or MIT (Merchant-Initiated Transaction) - and still leverage network tokenisation. This flow does not require a merchant token to be present on the gateway, enabling secure and flexible processing.

How to configure

Enable this feature in the user interface of the Smart Payments Platform, following the path in the configuration: Administration > Processing > Network Tokenisation > Process one-time payments with network tokens (default: false).

This update ensures efficient and compliant transactions for one-time payments.

2025-02-19

This release relates to tokenisation.

Peach Payments is pleased to announce enhancements to the network tokenisation process to ensure that cards are tokenised before 3DS or payment in the payment workflow. This update streamlines the payment process, providing a more efficient and secure transaction experience, especially for customers transitioning to network tokens.

What's new

Tokenisation before 3DS or payment: Cards are now network tokenised before 3DS or payment. The system checks if the network token is active and uses it if available; otherwise, it falls back to the PAN.
Optimised workflow: This change enables the system to leverage network tokens sooner, assuming they are provisioned by the schemes and approved by the issuer.

2025-02-19

This release relates to tokenisation.

On October 23, 2024, Peach Payments released a significant improvement to omni tokens management. Development continued, and today, omnichannel customers can leverage network tokenisation for their omni tokens across channels. This enhancement currently supports server-to-server integration, with future support planned for COPYandPAY. It provides several benefits:

Higher authorisation rates: Leverage higher acceptance rates with networks and issuers.
Better incentives: Gain better incentives when transacting due to adherence to network rules.
Enhanced visibility: All payments made with omni tokens are now visible in the Payment Orchestration Platform.
Onboarding: You are now required to first onboard with card networks before network tokens can be used in payments.

This update ensures that omnichannel customers can maximise the advantages of network tokenisation, leading to more efficient and successful transactions.

2025-02-11

This release relates to security.

To maintain security best practices, Peach Payments is introducing a preparatory step for the secure storage of API Bearer tokens used in transaction requests. Whilst these tokens are currently not hashed, Peach Payments is taking steps to ensure they are securely stored from creation.

Key points

Token creation: An API Bearer token is generated and displayed in a pop-up when a merchant entity is created. Store it securely in your vault.
Future hashing: Tokens are hashed before storage in future updates.
Irrecoverable tokens (future): Once hashed, tokens cannot be recovered. New tokens must be generated if needed.

This step is crucial for enhancing transaction security and protecting your API Bearer tokens. Stay tuned for further updates!

2024-12-09

This release relates to 3-D Secure.

Peach Payments acknowledges that the compulsory 3-D Secure flow for the integration with Mastercard Payment Gateway Services (MPGS) is a limitation for some customers. The list of values has been extended sent in the apiOperation parameter to MPGS. The apiOperation parameter was always used to initiate the 3-D Secure flow on the acquirer side. Now, it can be used to either execute or bypass the 3-D Secure flow on the acquirer side.

2024-10-23

This release relates to tokenisation.

Peach Payments is pleased to announce significant improvements to the omni tokens management system, designed to boost security and efficiency. This new version currently supports server-to-server integration, with future support planned for COPYandPAY.

Key highlights

New merchant tokens: Omni tokens are innovative merchant tokens, central to the Token Vault concept, and are used in both eCommerce and in-store transactions.
Server-to-server integration: Ensures robust and secure token management with server-to-server integration.
New payment types: Every omni token creation now uses paymentType=TK in the system. When performing a payment using the omni token as a merchant token, the omni token is detokenised from the Token Vault to retrieve the Full Primary Account Number (FPAN), and a new paymentType=DT is created. Fraud screening continues with the FPAN.
Enhanced visibility: Omni tokens now have enhanced visibility in the system for both customers and internally (Support teams), covering billing requirements.
UI configuration: Enablement for the new version is done via UI configuration. Onboarding with the Token Vault is required before turning on the usage of new omni tokens.

This update provides a more secure and efficient way to manage omni tokens, ensuring seamless integration and enhanced fraud protection.

2024-10-07

This release relates to tokenisation.

Peach Payments has introduced a new function that activates before the OneClick card form is submitted: onBeforeSubmitOneClickCardPromise(). This function returns a Promise object, guiding the next steps based on the outcome of an asynchronous operation.

2024-09-30

This release relates to industry standards.

As part of Peach Payments' ongoing commitment to ensure the highest standards of security and compliance, the solution remains compliant with the Payment Card Industry Data Security Standard (PCI DSS) v4.0. Effective March 31, 2024, this latest version brings changes designed to enhance security, flexibility, and risk management. Technical alignment is complete, and a new guide was, for the following areas:

Management of payment page scripts for COPYandPAY
Detection and response to unauthorised changes
Enhanced administrator compliance
Upcoming hashing requirements

For more detailed information on how to reach compliance with these requirements using Peach Payments products, refer to the PCI DSS Guide.