feat(connector): [STRIPE] Google Pay decryption, and route predecrypted wallets through /v1/tokens

[pixincreate]

What

Two things: adding Google Pay decryption support for Stripe, and fixing a pre-existing bug that meant no predecrypted wallet ever worked on this connector.

1. Google Pay decryption was missing

Stripe only accepts a Google Pay credential for later merchant-initiated transactions as a network token (PAN + cryptogram). TryFrom<&GooglePayWalletData> read only the encrypted token and errored on GpayTokenizationData::Decrypted, so Google Pay with setup_future_usage could not be set up at all.

Adds StripeWallet::GooglePayPredecryptToken / StripeGooglePayPredecrypt (tokenization_method = android_pay). A PAN_ONLY token — no cryptogram or ECI — falls back to a plain card. auth_type is threaded through the wallet conversions so that fallback can set request_three_d_secure.

2. Predecrypted wallets were posted to the wrong endpoint

Found while testing the above. Apple Pay predecrypt was equally broken and predates this branch.

The predecrypt structs serialize a top-level card[number] / card[cryptogram] / card[eci] / card[tokenization_method] block, which is only legal on /v1/tokens. Authorize flattened it straight into /v1/payment_intents. Replaying the exact bytes:

Endpoint	Result
POST /v1/tokens	200 — returns tok_..., card.tokenization_method: "android_pay"
POST /v1/payment_methods	400 — unknown parameters tokenization_method, eci, cryptogram
POST /v1/payment_intents (what this connector did)	400 — parameter_unknown, param: "card"

Fix:

• The PaymentMethodToken flow's get_url splits by payment method: Wallet → v1/tokens, everything else stays v1/payment_methods. Card tokenization already round-trips coherently (/v1/payment_methods → pm_ → payment_method=pm_) and is left alone.
• New StripeCardTokenPayment (payment_method_data[card][token]). Authorize splits an incoming PaymentMethodToken on the tok_ prefix — a token goes to payment_method_data[card][token], a pm_ still goes to payment_method. The prefix determines the Stripe object type, which determines the legal parameter.
• A decrypted wallet passed directly to Authorize fails fast with an actionable message instead of a request Stripe is guaranteed to reject.

3. Predecrypted Google Pay was excluded from tokenization

should_do_payment_method_token returned false for Google Pay unconditionally, so the composite service skipped tokenization and the decrypted payload hit the guard above — the feature was unreachable through the normal flow. Apple Pay was unaffected.

Removing the exclusion outright would break encrypted Google Pay, which must go direct to Authorize as GooglepayToken. The trait signature could not express the difference, so should_do_payment_method_token gains an is_wallet_pre_decrypted flag (default false, so the nine other implementors are behaviourally untouched), and the composite service derives it from the request payload's wallet oneof. Stripe's rule becomes: wallet and (not Google Pay or the payload is predecrypted).

Net routing, which matches the connector's documented contract:

Case	Tokenized first?
Apple Pay	yes
Google Pay encrypted	no — direct to Authorize as GooglepayToken
Google Pay decrypted	yes — /v1/tokens then payment_method_data[card][token]

No inline tokenization from Authorize. Stripe tokens are single-use and short-lived, so an inline mint would leak a token on every Authorize retry, and the composite Authorize has no tokenize step to chain through.

Testing — real Stripe sandbox

Driven through the composite path (the one that consults should_do_payment_method_token), not by calling Tokenize by hand — calling it manually is what masked bug 3 the first time.

#	Check	Endpoint(s)	Result
a	Card Authorize baseline	/v1/payment_intents, payment_method_data[card][number]	CHARGED pi_3U4Gj8D5R7gDAGff1MD8kEfX
b	Google Pay decrypted, cryptogram + ECI	/v1/tokens → tok_, then payment_method_data[card][token]	CHARGED pi_3U4Gk2D5R7gDAGff0Y7Ey1yj — was 400
c	Google Pay encrypted	no tokenization call; direct Authorize as GooglepayToken	CHARGED pi_3U4GknD5R7gDAGff0zLUkNMQ
d	Apple Pay decrypted	/v1/tokens → tok_, then payment_method_data[card][token]	CHARGED pi_3U4Gl6D5R7gDAGff0fho2ZIv — was 400
e	Google Pay decrypted + setup_future_usage=OFF_SESSION	as (b) plus setup_future_usage=off_session	CHARGED pi_3U4GlgD5R7gDAGff1ypGbKez, mandate pm_1U4GlgD5R7gDAGffNEmYd3Ow
f	Card tokenization regression	/v1/payment_methods → pm_, payment_method=pm_	CHARGED pi_3U4CDrD5R7gDAGff0r5570px
g	Guard	decrypted wallet posted straight to Authorize	rejected locally, no HTTP emitted

Case (c) is the regression risk of change 3 and is clean in both directions.

Outgoing body for (b), POST /v1/tokens:

card[number]=...&card[exp_year]=2030&card[exp_month]=08
&card[cryptogram]=...&card[eci]=05&card[tokenization_method]=android_pay

then POST /v1/payment_intents:

payment_method_data[type]=card&payment_method_data[card][token]=tok_...
&capture_method=automatic&expand[0]=latest_charge

cargo clippy -p connector-integration --all-targets, -p composite-service -p interfaces -p grpc-server, cargo check --workspace --all-targets and cargo fmt --check all clean.

Known adjacent issue, deliberately not changed

RepeatPayment has the same payment_method = token assignment and would mishandle a tok_. Unreachable in practice — MIT uses a stored mandate id — so it was left rather than changing an untested path, but it is the next place this bug class surfaces.

🤖 Generated with Claude Code