How does tokenization work in Omno?
When a customer enters card details in the hosted checkout, the card number goes straight to Omno’s PCI DSS compliant environment. It never passes through your servers. If the customer chooses to save the card, Omno stores it securely and creates a token: a reference that identifies the card inside Omno but has no value anywhere else.
Your backend receives the token, the card brand and the last four digits, which are enough to show the customer which card they used. On the next visit, the checkout shows the saved card and the customer can pay with it. Omno uses the token to retrieve the card internally, applies eligibility and routing, and sends the payment to a provider. The outcome arrives by webhook as for any other payment.
Saved cards are tied to the customer identifier you send when you create the checkout session. Use a stable ID from your own customer records, not an email address or a session value that can change, otherwise a returning customer will not see their card. If one person holds accounts on several of your brands, multi-merchant management decides whether a card saved on one brand is visible on another, so keep that choice in line with your privacy notice.
Some payments still need the customer. Issuers may ask for 3-D Secure authentication on a payment with a saved card, especially on a first payment after a long gap or on a larger amount. The checkout handles that step in the same flow, and the webhook reports the result as usual.
Why do saved cards matter for conversion?
Typing a card number on a phone is slow and error-prone. Each extra field is a chance for a typo, an expired date or an abandoned payment. Returning customers who can pay with a saved card skip that step, which matters most where customers pay often, such as repeat orders in e-commerce.
Saved cards also feed the rest of the platform. Customer profiling links payment methods and history to a customer, so rules can treat a returning customer with a clean history differently from a first-time payer. Combined with card blocking, the same profile helps stop a card that was involved in a chargeback from being used again.
What changes versus a single PSP?
Many PSPs offer their own card vault. The catch is that their tokens only work with them. If you want to move volume to a second provider, or cascade a declined payment to another acquirer, the first provider’s token is useless there, and the customer has to type the card again.
With Omno, cards are saved in the orchestration layer rather than in one provider’s vault. The same saved card can go to whichever eligible provider routing selects, and it can move to the next provider in the rule when the first rejects the payment. Changing providers does not mean asking customers to re-enter their cards. You also keep one set of tokens and one customer profile across all providers, instead of a different vault for each.
How does tokenization reduce PCI DSS scope?
PCI DSS applies to every system that stores, processes or transmits cardholder data, and to systems connected to them. If card numbers reach your servers, those servers, the networks around them and the people who manage them all come into scope. That means more controls, more evidence and more audit work.
When card capture happens in the hosted checkout and storage happens in Omno’s vault, your systems only ever handle tokens. That shrinks the environment you need to assess. It does not remove every obligation, because the pages that load the checkout and the way you handle tokens still matter. Confirm your exact scope with your qualified security assessor, and see the security page for Omno’s own PCI DSS status.