/// work · loyalty · react · azure

Global consumer brand — transactional loyalty portal

Member registration, card wallet, reloads, transfers, e-gifts and program tiers, for Mexico and Chile on a single codebase.

budget> $25,000 USD
statusCompleted
engagementCollaboration
technologyReact · Azure
sectorRetail / loyalty
marketsMexico · Chile
servicesFrontend architecture, development, payment and anti-fraud integrations
/// context

A global consumer brand needed the web portal for its loyalty program in Mexico and Chile: member registration, a wallet of stored-value cards, reloads with bank cards, balance transfers, digital gift cards (e-gifts), program tiers and loyalty-point accrual.

The application was built in React as a whitelabel product: one codebase, configurable per country.

/// the problem

The portal handles money: reloads, balances and e-gift purchases with bank cards. That imposes four constraints:

  • Controlled PCI scope. Keep the frontend outside strict PCI DSS scope through tokenization.
  • Account-level fraud prevention, with device telemetry embedded in session flows.
  • OTP verification for high-value operations: reloads above threshold, auto-reload setup and email changes.
  • Gateway independence. The payment provider can change per country or per contract; the application cannot be coupled to one.
/// the solution

Payment layer with an adapter pattern

The application does not interact with gateway SDKs inside business views: it works against an abstract interface —initialization, device fingerprint, tokenization, charge— and each provider (OpenPay, Stripe, Adyen) is implemented as a swappable adapter. Changing gateways is a configuration change, not a rewrite.

Tokenization and PCI scope

Bank card data is captured and tokenized through the active gateway; the frontend transacts with tokens, keeping the application outside strict PCI DSS scope.

Request signing and fraud prevention

Critical endpoints —authentication, token refresh, registration— are signed with SHA-256 over a timestamp, with per-channel verification headers. The anti-fraud system's device telemetry is collected client-side and travels embedded in session flows for per-transaction risk evaluation.

OTP verification for high-value operations

Reloads above threshold, auto-reload configuration and email changes require a temporary token generated and validated by the API before the operation executes.

Wallet and transactions

The member's cards are sorted by balance and show real-time balance. Flows cover bank-card reloads, balance transfers between own cards, auto-reload and a consolidated transaction history: purchases, reloads, promotions and point expiration.

e-Gifts

A catalog by category with designs per occasion, customization of amount, sender, recipient and message, payment with a bank card and delivery by email to the recipient.

Whitelabel per country

One codebase with per-market configuration: local rules, payment providers and content for Mexico and Chile, with functional parity between both.

/// results
  • Transactional portal in production for two markets on a single codebase.
  • The payment architecture allows switching charge providers by configuration, without rewriting business flows.
  • Fraud controls and OTP operate without visible friction for the user in normal operations.

stack: react · azure · api gateway · oauth 2 · sha-256 request signing · payment tokenization · otp