Tokenization is easy to explain in one sentence — replace the card number with a safe reference value — and hard to explain in any more depth, because the industry uses one word to describe at least three different things. For parking operators, the distinction that matters most is between transaction tokens issued by the payment gateway or acquirer, and customer account tokens issued by the card network. They look similar, store similar data, and defeat similar attacks — but they are managed differently, expire differently, and suit different use cases.

Transaction Tokens

A transaction token (sometimes called a gateway token, merchant token, or acquirer token) is a reference generated by the payment gateway when the card is first processed. The token is typically specific to the merchant and the gateway — it cannot be used anywhere else. When the merchant wants to charge the same card again, the gateway exchanges the token for the real card number inside its vault and processes the transaction.

Transaction tokens satisfy PCI scope reduction — the merchant’s systems never hold the PAN, only the token. They do not, however, provide network-level protections against card lifecycle events. When the cardholder receives a new card (reissue, expiry, lost/stolen replacement), the gateway’s stored vault entry becomes stale and the token starts declining. The merchant then has to reach out to the cardholder to re-enter the card.

Network Tokens (Customer Account Tokens)

A network token is issued by the card network itself through EMVCo’s tokenization specification, published at EMVCo’s Payment Tokenisation page. The token is bound to the network and the token requestor (the merchant or their wallet provider), and the network maintains the mapping between the token and the current underlying card — including through reissue and replacement.

When the cardholder gets a new card because the old one expired or was lost, the network token keeps working. The network quietly updates the underlying PAN mapping, and the merchant’s stored token continues to authorize successfully. This is the main reason card-on-file merchants — parking included — have been adopting network tokens.

Network tokens also carry additional risk-management benefits. Transactions on network tokens are flagged to the issuer as token-authenticated, which can influence authorization-decline rates and chargeback liability. Some networks publish preferential interchange rates for network-tokenized card-on-file transactions.

Which to Use for Which Parking Use Case

Hourly pay-station transactions

Most single-use pay-station taps do not need either kind of token long-term. The transaction is one-and-done. If the acquirer tokenizes in transit for PCI scope, that is a gateway token used for the receipt and reconciliation pipeline, not stored for future billing.

Mobile parking app first transaction

First charge on a new card in a parking app is typically a card-not-present authorization that returns a gateway token. Modern apps increasingly provision a network token at the same time so that future charges benefit from network-token handling.

Monthly parking subscriptions

Monthly parking is the highest-value use case for network tokens. A monthly charge that declines because the cardholder got a new card is a churn event — the parker either updates their card or they leave. Network tokens reduce that decline rate materially by handling reissue transparently. For a large monthly parking operation this compounds into better retention and lower customer-service load.

Saved cards for reservations

Airport parking reservations with saved cards for no-show charges, or event parking with pre-booked spaces, benefit from network tokens for the same reason monthly parking does.

Wallet top-ups

Stored-balance parking wallets that reload from a card on file should use network tokens where supported. The reload is a merchant-initiated transaction against a stored credential — exactly the flow the network-token model was designed for.

Implementation Model

In practice most parking operators do not implement tokenization themselves. The gateway or payment service provider manages both the gateway vault and the network-token provisioning. The operator’s job is to:

  • Confirm the gateway supports network tokens for the card networks the operator accepts.
  • Understand whether network tokens are provisioned automatically or on merchant request.
  • Monitor decline rates on stored-credential transactions as a network-token effectiveness metric.
  • Flag recurring charges correctly as MIT (merchant-initiated transactions) against a stored credential, per EMV and scheme rules.

Security Model

Both token types remove PAN storage from merchant systems, reducing the impact of a breach. Network tokens add the property that a compromised token is effectively useless outside the specific merchant it was issued to, because the network enforces the token-requestor binding. Gateway tokens have similar binding at the gateway level but lack network enforcement.

The PCI Security Standards Council has endorsed tokenization as a PCI-scope-reduction control in PCI DSS and in separate tokenization guidance. Both transaction tokens and network tokens qualify when implemented to the applicable standard.

FAQ

Does tokenization replace encryption?

No. Tokens replace stored card data; encryption protects card data in transit and at rest in systems that still handle it. A mature stack uses both — tokens for persistent storage, encryption for live processing.

Do all card networks support network tokens?

Visa Token Service and Mastercard Digital Enablement Service (MDES) are the largest. American Express and Discover run their own equivalents. JCB, UnionPay, and regional networks have varying support. Check with your gateway for supported networks.

Will a network token work if the cardholder closes the account?

No. Closure is different from reissue — the network removes the mapping and the token returns a decline. Reissue (new plastic, same account) is handled transparently; closure is a hard stop.

Can a gateway token become a network token later?

Yes. Gateways commonly support upgrading stored cards to network tokens on a scheduled migration. Once upgraded, future authorizations run on the network-token rail automatically.