// Case study · Fintech / payments

Card tokenization & hosted fields

PCI-safe card capture and reusable tokens — keep raw card data out of merchant systems while still supporting one-click and recurring payments.

Software Developer → Team Lead · On a payment-orchestration platform.

The problem

Handling raw card numbers drags every system into PCI scope. Merchants still need saved cards, one-click and recurring payments — so the platform had to capture cards safely and hand back reusable tokens.

The approach

Hosted fields capture card data in an isolated surface, out of the merchant's page and scope; customer account tokens represent saved instruments; and cached IIN / BIN lookup drives routing and UX without touching the full number.

The decision & trade-off

Pushed card data behind hosted fields and tokens even where it added integration steps for merchants — minimizing PCI scope was worth the extra surface to build and maintain.

Architecture

Hosted fields → tokenized instrument → customer account token; IIN details cached in Redis for fast routing; the raw card never lands in merchant systems.

Outcome

Saved cards, one-click and recurring flows on a tokenized foundation, with card data kept out of scope.

What I'd do differently

Standardize the token lifecycle — rotation, expiry, portability — earlier as a first-class concern rather than growing it per feature.

Architecture diagram

Card Tokenization & Hosted Fields — Raw card data never lands in merchant systems — capture, cache, tokenize. Payment Orchestration Platform [Software System] Hosted Fields[Container: Isolated capture surface] Tokenization Service[Container] IIN / BIN Cache[Container: Redis] Cardholder[Person] Merchant System[External System] Enter card[PCI-scoped] Card data Cache IIN/BIN Customer token[Tokenized] Card Tokenization & Hosted Fields Raw card data never lands in merchant systems — capture, cache, tokenize.

Stack

  • PHP
  • Symfony
  • Redis
  • PCI DSS

Have a similar problem?

Tell me about it — I reply within a day.