Retail


scope, bringing requirements around security controls, monitoring, documentation and assessment. Limiting raw card data to fewer systems makes access easier to


control and reduces the amount exposed if one of those systems is breached. A new wallet, checkout flow, provider or fraud tool can alter the route taken by payment data, so technology and compliance teams need to review the revised flow and confirm that the controls still fit. Retailers with several channels have another layer to deal with.


Online orders, in-store returns, app payments and subscriptions can rely on different systems while sharing parts of the same customer journey. A refund started through customer service can depend on a credential stored by an e-commerce provider, while a saved card created in an app can later support another purchase. Each team needs a different part of the payment record. Customer


service needs enough information to trace the order and process the refund, finance works from the transaction and settlement details, and fraud teams look at the activity around the payment. The card credential itself can remain in the system built to protect it - the vault.


Keep the payment data that earns its place Retailers get real value from the trail a payment leaves behind. It can explain why a transaction failed, show whether a retry recovered the sale and reveal when one provider is underperforming. Finance, fraud and payment teams all use that information in different ways. Raw card details serve a much narrower purpose. Reporting,


loyalty, customer service and analytics systems can work from a token, masked card number or transaction reference. Keeping the sensitive form of the credential out of those systems reduces exposure while preserving the information needed to run the business. Tokenisation makes that separation possible by replacing the


Primary Account Number, the long number associated with the card, with a substitute reference. Retailers can support repeat payments, saved cards and refunds without sending the card number through every connected application. Retailers need to look beyond whether card data has been tokenised


and ask where that token will work. A token created inside one PSP’s vault can leave saved cards tied to that provider long after the business wants to route payments elsewhere.


Stored cards need to work beyond one provider PSP-native vaulting can suit a straightforward setup in which one PSP handles most transactions. Its limits become clear as soon as another route is added. New customers can go through the new provider, while anyone paying with a saved card remains tied to the original one. If the first provider goes down, the fallback only covers part of the customer base. Retailers often discover this when they expand into a new market.


The local acquirer can take new payments, but customers would have to re-enter their card details, and the retailer would have to re-tokenise behind the scenes to enable that new acquirer to process the transaction in the same way as the old route. Network tokens work at card-scheme level (i.e. Visa, Mastercard


etc) rather than inside one PSP’s vault, so they can support a wider range of providers. Visa has reported a 4.6% global lift in authorisation rates for tokenised card-not-present transactions compared with PAN-based transactions. Network tokens are also automatically


www.pcr-online.biz


updated by the card issuer when a card expires or is reissued. Account updater services perform a similar job for stored credentials, making sure that any changes to stored cards are processed behind the scenes, completely invisible to the end customer. Retailers should ask about token portability before signing with a


provider: where will the token work, who controls it and what happens to saved cards if the route changes?


Keep saved cards independent of the provider An independent vault enables stored credentials to be safely protected outside both the merchant and the PSP’s own environments, increasing flexibility and reducing compliance burdens. Checkout, apps and customer accounts continue to use tokens, while the vault supplies the credential to the approved provider selected for the payment. A new PSP or local acquirer can take payments from returning


customers seamlessly as well as those entering a new card at the checkout. The customer keeps using the saved card, while the retailer chooses the route behind it. The vault still needs strong access controls, governance and supplier


oversight. Its value lies in keeping sensitive card data in a defined part of the payment environment and cutting down the number of systems that touch it.


Orchestration connects the data and the route Payment orchestration connects checkout, the vault and the provider network, then applies routing, retry and failover rules to optimise performance. Transactions can move according to market, payment method, provider performance or availability, and new connections can be introduced through a common layer instead of being built separately into each channel. The retailer also gets a consolidated view of approval rates, failures,


retries and refunds across providers. Teams can see where traffic should move and which routes need attention. Routing flexibility and control are only possible if saved cards can


move with the traffic. Holding the credential independently means returning customers can use another provider too if the main route slows or fails.


Keep the intelligence, shorten the route taken by sensitive data Retail payment environments will continue to expand because customers expect more choice and retailers need more ways to improve acceptance and resilience. More providers, channels and payment methods create useful options and richer information about performance. The infrastructure behind that growth needs a clear distinction


between the data used to run payments and the sensitive credentials used to complete them. Performance information should reach the teams using it, while raw card data and stored credentials remain within a tightly controlled part of the setup. That distinction lets retailers use a broad provider mix, change


routes and preserve saved-card journeys without risking the oversharing of card details. Payment data should keep helping retailers make better decisions. Sensitive card data should have a much shorter journey.


July/August 2026 | 7


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52