Mobile Payment Tokenization Patterns

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:
4. The key material
5. The card data (PAN/CVV/expiry) interpolated into JS literals
6. A <script> block that calls into an exposed @JavascriptInterface
7. The app dispatches the JS into a WebView with setJavaScriptEnabled(true).
8. The WebView's encryption JS produces an opaque token, which the bridge returns to native code.
9. 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]].