Personalization
BIN Lookup | Preferred Method | GEO Context | PSP Success Rate
Purpose
Personalization makes the checkout smarter for returning players. Instead of showing all available methods in a fixed order, the system surfaces the most relevant method first -- the one the player is most likely to complete a transaction with.
Two primary signals drive personalization: BIN lookup (the first 6-8 digits of the card number identify the issuing bank, card type, and country) and last successful method per player. These are cheap, deterministic, and available before the player makes any interaction.
The goal is measurable: reduce checkout abandonment and increase first-attempt success rate. Personalization is always additive -- it reorders the method list, never removes options the player is entitled to use.
Personalization Signals
BIN Lookup
Bank Identification Number -- the first 6 to 8 digits of any card number. Identifies issuer, card network, card type (debit/credit/prepaid), and issuing country before the player does anything.
INPUTS
- First 6-8 digits typed by the player in the card number field
- BIN database (updated weekly from card network feeds)
OUTPUTS
- Card network: Visa / Mastercard / Maestro / Amex / etc.
- Card type: debit / credit / prepaid / corporate
- Issuing country (ISO 3166-1 alpha-2)
- Issuing bank name
BACKEND
BIN lookup must complete in < 10 ms. Use an in-process BIN database (e.g. Redis hash or embedded SQLite) -- do not call an external API per keystroke. Expose as GET /api/bin/:prefix returning the enriched card info object.
Last Successful Method
The simplest and most powerful personalization signal. If a player successfully deposited via Visa last time, offer Visa first next time. No ML required.
INPUTS
- player_id + brand_id + direction (deposit/withdrawal)
- Transaction history: status = COMPLETED
OUTPUTS
- Preferred method slug (e.g. "visa", "crypto_usdt")
- Timestamp of last success (used for staleness check)
- Success count (used for confidence scoring)
BACKEND
Store as a materialized view or denormalized record on the player profile -- do not query transaction history on every checkout load. Update the record asynchronously when a COMPLETED event fires. TTL: treat a preferred method as stale if no successful use in 90 days.
GEO + Device Context
IP geolocation and device type enrich the signal set without requiring any player action. Used to infer local payment preferences and to apply device-specific method ordering configured in the Admin Panel.
INPUTS
- IP address → country code (MaxMind GeoIP or equivalent, in-process)
- User-Agent → device type: mobile / desktop / tablet
OUTPUTS
- Country code for method filtering and GEO-based ordering
- Device type for selecting the correct display order list from Admin Panel
BACKEND
GEO resolution must be in-process (< 1 ms). Never call an external geolocation API in the checkout critical path. The resolved country is also used by the Orchestrator for routing -- share the resolved value via the request context object, do not resolve twice.
PSP Success Rate per Method
When multiple PSPs support the same method, route to the one with the best recent success rate for that method + GEO combination. This is routing optimization, not player-level personalization -- but it directly improves the player's experience.
INPUTS
- Transaction history (last 24h): psp_id + method_id + country + status
- PSP health scores from the Admin Panel monitoring background job
OUTPUTS
- Per-(psp, method, country) success rate: float 0.0 -- 1.0
- Ranked PSP list for a given (method + country) pair
BACKEND
Computed as a rolling window aggregate (last 500 transactions or last 24 h, whichever is smaller). Store pre-computed in Redis and refresh every 5 minutes via a background job. The Orchestrator reads this ranking when building the PSP cascade chain.
Method Ranking Logic
Condition
Player has a preferred method AND it is available AND last used < 90 days ago
Result
Preferred method goes first with "Recommended" badge
Condition
BIN lookup returns a specific card network (e.g. Mastercard) and that network is available
Result
Matching card network method promoted to top of card group
Condition
GEO country has a dominant local payment method (e.g. BLIK in Poland)
Result
Local method ranked second (after preferred if present)
Condition
No personalization signals available (new player, no BIN typed)
Result
Admin Panel device-specific display order is used as-is
Personalized Checkout Flow
Checkout session init
BEPlayer opens checkout. Backend resolves: player profile (last preferred method), GEO from IP, device type from User-Agent, available methods for brand + country. Returns enriched method list with a "recommended" flag on the top candidate.
Method list render
FEFrontend renders the method list in the order provided by the backend. The recommended method is visually highlighted (e.g. "Recommended" badge). No reordering logic in the frontend -- the backend owns the sort.
Card number BIN trigger
FEWhen the player selects "card" and types 6+ digits, frontend calls GET /api/bin/:prefix. Response enriches the UI: shows card network logo, card type label. If BIN indicates a card from a country different from GEO, backend may suggest a different PSP silently.
PSP selection with personalization
BEOn transaction submit, Orchestrator enriches routing context with: BIN country (if card), player's preferred method, PSP success rates. Routing rules are evaluated against this enriched context. The winning PSP is the intersection of routing rules + best success rate + active cascade priority.
Profile update on completion
BEWhen a transaction reaches COMPLETED status, an async event updates the player's preferred method record. If this was a card transaction, also store the masked BIN (first 6 digits) as a recognized card hint for next session.
API Contract
Used to fetch preferred method from player profile
Scopes available methods and personalization data
DEPOSIT | WITHDRAWAL -- affects method availability
Resolved to country code server-side via GeoIP
Resolved to device type: mobile / desktop / tablet
Optional. Provided by FE after player types 6+ card digits
Ordered list of available methods. Order is the final personalized order.
e.g. "visa", "mastercard", "crypto_usdt", "bank_transfer"
True for at most one method in the list -- the top personalization pick
H2H | INVOICE_LINK -- determines checkout flow in FE
If bin_prefix was provided: { network, card_type, issuer_country }
Privacy & Compliance
- Never store full card numbers -- only the first 6-8 digits (BIN prefix) and last 4 digits, as per PCI DSS
- Player's preferred method record contains only the method slug -- not card details, not PSP transaction IDs
- BIN lookup is done client-side and server-side; the full card number never leaves the player's browser in the BIN request
- Personalization data is scoped per brand: player preferences from Brand A are not used on Brand B
- Player can clear their payment history and preferred method via account settings (GDPR right to erasure)