Mobile Payment Tokenization Patterns

Use this skill when reviewing mobile code that handles card data, payment tokenization, or third-party payment SDK integrations (Braintree, Stripe, Adyen, Google Pay, Apple Pay, FirstData-style iframe encryptors). The skill catalogues the high-signal attack patterns vuln-scout detects in mobile payment flows — server-controlled tokenization URLs, JavaScript-injection-into-WebView card-data exfiltration, JS-bridge token construction, and payment scope mismatches — and maps each to the detector that fires.

14 stars

byallsmog

View on GitHub Installation ↓

Best use case

Mobile Payment Tokenization Patterns is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Teams using Mobile Payment Tokenization Patterns should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

You only need a quick one-off answer and do not need a reusable workflow.
You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/mobile-payments/SKILL.md --create-dirs "https://raw.githubusercontent.com/allsmog/vuln-scout/main/vuln-scout/skills/mobile-payments/SKILL.md"

Manual Installation

Download SKILL.md from GitHub
Place it in .claude/skills/mobile-payments/SKILL.md inside your project
Restart your AI agent — it will auto-discover the skill

How Mobile Payment Tokenization Patterns Compares

Feature / Agent	Mobile Payment Tokenization Patterns	Standard Approach
Platform Support	Not specified	Limited / Varies
Context Awareness	High	Baseline
Installation Complexity	Unknown	N/A

Frequently Asked Questions

What does this skill do?

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Mobile Payment Tokenization Patterns

## When this skill applies

The user is reviewing mobile (Android/iOS) code that handles:

- Card tokenization (PAN/CVV/expiry → opaque token)
- Payment processor SDK integration (Braintree, Stripe, Adyen, FirstData-
  style iframe encryptors)
- Wallets (Google Pay, Apple Pay, Cash App, Venmo)
- Encrypted PAN encryption in WebViews
- Issuer / PIE (Public Initialization Encryption) key management

Signals: files under `**/payment/**`, `**/checkout/**`, `**/tokenize*/**`, `**/services/**/api/`, mentions of "PIE key", "iframe shim", "EncryptionListener", "PaymentMethodType".

## The PIE / iframe-shim / Braintree tokenization shape

Most modern card tokenization on Android follows this template:

1. The app fetches an **encryption key** (RSA pubkey or symmetric salt) from a backend.
2. The app fetches the **tokenization endpoint URL** from a backend.
3. The app builds a **JavaScript payload** that contains:
   - The key material
   - The card data (PAN/CVV/expiry) interpolated into JS literals
   - A `<script>` block that calls into an exposed `@JavascriptInterface`
4. The app dispatches the JS into a **WebView** with `setJavaScriptEnabled(true)`.
5. The WebView's encryption JS produces an opaque token, which the bridge returns to native code.
6. The native code submits the token to the processor over HTTPS.

Each step has a corresponding VulnScout detector:

| Step | Detector | What goes wrong |
|---|---|---|
| 2 (URL fetched) | `mobile-remote-controlled-endpoint` | Backend supplies an attacker-controlled URL; client follows it. |
| 1 (key fetched) | `mobile-webview-js-injection` | Key material is spliced into a JS literal unescaped — break out, run JS. |
| 3-4 (JS dispatch) | `mobile-webview-js-injection`, `mobile-webview-file-access`, `mobile-webview-js-interface` | WebView config or @JavascriptInterface exposes native callbacks. |
| 5 (bridge) | `mobile-js-bridge-payment-token` | Native token object is constructed from JS-controlled values. |
| 6 (submit) | `mobile-nsc-narrow-pinning`, `mobile-nsc-no-pinning`, `mobile-insecure-tls` | Cert pinning gap on the processor host allows MITM of the token. |

## What a real hit looks like

When the detectors fire on a payment flow you should expect to see a cluster
along these lines (file names will differ; the *shape* is what matters):

| Detector type | File shape | Notes |
|---|---|---|
| `mobile-remote-controlled-endpoint` | a `*TokenizeCardApi` / `*PaymentApi` class | a `*_URL` key is pulled from remote config and dispatched via OkHttp / Retrofit / a custom `CoroutineCallFactory`. |
| `mobile-webview-js-injection` | a tokenization helper under `**/payment/**/js/` | PIE/RSA key material + PAN/CVV spliced into a `<script>` literal via StringBuilder. |
| `mobile-js-bridge-payment-token` | a sibling `EncryptionListener` / `*Bridge` class | `@JavascriptInterface onEncryptionComplete` builds the native token object. |
| `mobile-nsc-narrow-pinning` | `apktool_out/res/xml/network_security_config.xml` | pin-set covers a single advertising/SDK domain while every payment / identity / config host still relies on system CA. |
| `mobile-shared-prefs-sensitive` | an auth/identity package | access token / refresh token written to plain SharedPreferences. |
| `payment-client-token-scope-mismatch` | a Braintree wrapper | hardcoded `ExternalPaymentProcessor.X` + `PaymentMethodType.Y` may reuse the token outside its intended scope. |

## Chain to look for

Two detectors in the same payment package + a manifest-side pinning gap = a complete card-data exfiltration primitive. VulnScout's `chain_detector.py` auto-builds this as `Mobile WebView dispatch chain`.

## Cross-platform notes

- iOS equivalents: `ios-webview-evaljs-concat` (= `mobile-webview-js-injection`), `ios-ats-arbitrary-loads` (= `mobile-nsc-cleartext`), `ios-trust-all-ssl` (= `mobile-insecure-tls`).
- Cash App SDK / Square SDK use similar PIE-style flows — apply the same template.
- Google Pay tokens are wrapped server-side and don't follow this template; client-side findings on a Google Pay flow are usually informational.

See also: [[mobile-android]], [[mobile-ios]].

Related Skills

Vulnerability Patterns

from allsmog/vuln-scout

This skill should be used when the user asks about "vulnerability patterns", "how to find SQL injection", "XSS patterns", "command injection techniques", "OWASP vulnerabilities", "common web vulnerabilities", "exploitation patterns", or needs to understand how specific vulnerability classes work during whitebox security review.

Mobile iOS Whitebox Audit

from allsmog/vuln-scout

Use this skill when the user is auditing an iOS application — directory contains `.ipa`, `Info.plist`, `*.swift`, `*.m`, `*.mm`, or an `xcodeproj`. Also activates when the conversation mentions WKWebView, NSURLSession, Keychain, App Transport Security, or any `com.apple.*` / `bundleidentifier`-style iOS package name.

framework-patterns

from allsmog/vuln-scout

This skill should be used when the user asks about "framework vulnerabilities", "Next.js security", "Flask security", "Django security", "Rails security", "Spring security", "GraphQL security", "Server Actions", "render_template_string", "SSTI patterns", "redirect SSRF", "mass assignment", "actuator exposure", "SpEL injection", "introspection", or needs to identify framework-specific vulnerability patterns during whitebox security review.

Workspace Discovery

from allsmog/vuln-scout

This skill should be used when the user asks to "detect workspaces", "find packages", "list monorepo packages", "workspace structure", "monorepo analysis", or needs to identify workspace/package boundaries in a codebase for focused security analysis.

vulnerability-chains

from allsmog/vuln-scout

This skill should be used when the user asks about "vulnerability chains", "chained exploits", "multi-step attacks", "SSRF to RCE", "pivot attacks", or needs to identify how vulnerabilities in different components can be combined during whitebox security review.

Threat Modeling

from allsmog/vuln-scout

This skill should be used when the user asks about "threat model", "STRIDE", "data flow diagram", "attack surface", "threat analysis", "security architecture", "component threats", "trust boundaries", "technology decomposition", or needs systematic threat identification during whitebox security review.

verify-finding

from allsmog/vuln-scout

Drive a single finding through CPG verification and false-positive triage.

start-audit

from allsmog/vuln-scout

Guided first-run security audit: doctor, scope, threats, scan, verify, report.

scope-repo

from allsmog/vuln-scout

Decide audit boundaries for large or monorepo targets and write audit-plan.md.

review-pr

from allsmog/vuln-scout

Diff-aware PR security review with verified findings and PR comment payload.

package-evidence

from allsmog/vuln-scout

Bundle findings, reports, audit plan, and ledger into one evidence zip.

Sensitive Data Leakage

from allsmog/vuln-scout

Detect ANY credential/secret flowing to ANY output sink. Use when asked about "credential leakage", "secret logging", "sensitive data exposure", "CWE-532", "password in logs", "token exposure", or security logging issues.