feat(connector): [CHECKOUT] complete wallet decryption — mandates, token passthrough, and tokenization

[pixincreate]

What

Three gaps in Checkout's wallet handling.

1. Decrypted wallets were rejected by SetupMandate

Authorize already built ApplePayPredecrypt / GooglePayPredecrypt sources and set store_for_future_use: true on mandate payments, but the SetupMandate transformer matched only Card and AchBankDebit — a zero-amount mandate setup with Apple Pay or Google Pay was rejected as NotImplemented.

Extracted into build_predecrypted_wallet_source, now shared by Authorize and SetupMandate; magic strings lifted to named constants.

2. The connector-decryption path was unreachable

PaymentSource::Wallets was declared and never constructed, so a wallet Checkout should decrypt at its own end had nowhere to go, and an encrypted payload died with a misleading MissingRequiredField. Both Authorize and SetupMandate now consume PaymentMethodData::PaymentMethodToken and map it to source.type = "token".

3. UCS could not mint the token itself

Implements the PaymentMethodToken flow (POST /tokens, CheckoutTokenRequest / CheckoutTokenResponse) and removes it from not_implemented.

Auth uses the existing auth fields — no new credential. Checkout's /tokens authenticates with the account public key and /payments with the secret key. Those map onto CheckoutAuthType as api_key = public key, api_secret = secret key. build_tokenization_headers reads api_key; payment flows stay on api_secret. The mapping is counter-intuitive, so it is documented on CheckoutAuthType and at both header builders with an explicit warning against re-introducing a separate public-key field.

Verified on the sandbox: sk_ → /tokens = 403, pk_ → /tokens = 201, pk_ → /payments = 401.

No inline tokenization from Authorize. Checkout's tokens are single-use with a 15-minute expiry, so an inline mint would hide a second network call inside a request the caller believes is atomic and would break on retry. Callers tokenize first, then authorize.

Testing — real Checkout sandbox

Check	Result
Card Authorize baseline	CHARGED pay_wsibhwybbydibfsh45aj2wfa6m
Google Pay decrypted (Authorize)	Accepted 201; issuer simulator declined the dummy cryptogram (20068)
Tokenize auth via api_key	Credential accepted — 422 on payload, not 401/403
Missing-config error surface	Missing required field named precisely
Encrypted wallet → Authorize	Unimplemented, pointing at the tokenize step

Tokenization request bytes, verified against a capture server:

POST /tokens
authorization: Bearer <public key>
{"type":"applepay","token_data":{"version":"EC_v1","data":"…","signature":"…","header":{…}}}
{"type":"googlepay","token_data":{"protocolVersion":"ECv1","signature":"…","signedMessage":"…"}}

cargo clippy -p connector-integration --all-targets warning-free. No proto change — this PR touches only the two connector files plus generated docs/examples.

Not proven end to end

Minting a real tok_ and spending it in one pass is not demonstrated, for two reasons outside this code:

1. The available sandbox pk_ and sk_ are from different Checkout accounts. Proven with UCS out of the picture — mint with pk_ → 201; spend that token with sk_ → 422 token_invalid; control: the same sk_ charges a raw card → 201. Needs a pk_sbox_… from the same account as the sk_.
2. Wallet tokenization additionally needs a live wallet SDK payload and, for Apple Pay, a processing certificate. Hand-built payloads return merchant_certificate_not_found / token_data_invalid — wallet blobs are cryptographically signed and cannot be synthesized.

SetupMandate with a decrypted wallet (change 1) has also not been exercised against the sandbox.

Deliberate divergence: Google Pay ECI hardcoded to 06

GOOGLE_PAY_DEFAULT_ECI = "06" is sent for every decrypted Google Pay network token; eci_indicator is not read. Confirmed at runtime — input 05 reaches Checkout as 06.

This matches the upstream integration exactly, including the asymmetry that the Apple Pay path in the same file forwards the real ECI. Inherited, not introduced here — worldpayxml forwards 05 correctly for the same input.

Kept as-is on purpose so the two implementations stay byte-identical on this connector. Consequence worth knowing: 05 is fully-authenticated and 06 is attempted, so this forfeits the liability shift on CRYPTOGRAM_3DS tokens. Any fix should land on both sides together.

🤖 Generated with Claude Code