feat: install tokenizer package & enrich google pay callback data

[SanthoshCharanBolt]

Description

Moves wallet-payment tokenization (Apple Pay, Google Pay) from the native iOS/Android modules onto the JS side using the @boltpay/tokenizer package. Native modules now return the raw PKPayment / Google Pay payload, and a new useTkClient() hook tokenizes via TkClient.postApplePayToken() / postGooglePayToken(), which performs an asymmetric-encrypted POST to Bolt's tokenizer service. This aligns the RN SDK with the tokenizer pattern used on web and deletes the native HTTP tokenizer code (ApplePayModule.swift, GooglePayModule.kt) plus its fallback logic. react-native-get-random-values is added as a peerDependency so tweetnacl (inside @boltpay/tokenizer) has a secure PRNG on Hermes/JSC — the SDK side-effect-imports it internally, so consumers install the package once (documented in the README) and need no code changes. ApplePayResult drops last4 (the Apple Pay tokenizer never populates it — the decrypted payload only carries the DPAN) and keeps boltReference as an optional webview-only field.

Testing

• Jest unit suites updated and passing (src/__tests__/ApplePay.test.tsx, src/__tests__/WalletTypes.test.ts, src/__tests__/GoogleWallet.test.tsx) — 159/159 tests, plus typecheck + lint clean.
• Manual device validation:
  • Apple Pay native mode on iOS — PassKit sheet → raw payload → tkClient.postApplePayToken() → tokenized result delivered via onComplete.
  • Google Pay on Android (New Arch) — Google Pay sheet → raw payload → tkClient.postGooglePayToken() → tokenized result with bin, last4, expiry.
• Worth re-testing before merge: webview-mode Apple Pay (unchanged code path but uses the same ApplePayResult type which now has last4? added), error paths where tkClient.post*Token() returns an Error (re-thrown into onError), and fallback behavior if the tokenizer's primary host fails (TkClient retries the alternative host internally).

Security Review

Important

A security review is required for every PR in this repository to comply with PCI requirements.

• I have considered and reviewed security implications of this PR and included the summary below.

Security Impact Summary

This PR touches a PCI-relevant flow: wallet payment tokenization. The material change is where the encrypted tokenization request is assembled — previously the native module POSTed the raw PKPayment / Google Pay payload as JSON over HTTPS to *.bolttk.com; now the JS-side @boltpay/tokenizer encrypts the request body with the tokenizer service's public key (tweetnacl box) before POSTing. The payment payload is therefore end-to-end-encrypted between the device and the tokenizer service rather than relying only on TLS. No payment data is stored, logged, or exposed to consumer app code — the raw payload passes straight from the native module to TkClient and is discarded after tokenization. react-native-get-random-values (peer dep) is the widely-used RN bridge to platform CSPRNGs (SecRandomCopyBytes / java.security.SecureRandom); it is required because Hermes/JSC do not ship crypto.getRandomValues, and without it tweetnacl throws at keypair generation. No changes to stored tokens, Bolt API surface, or authentication.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.