Apple & Google Pay
The accepted source can render Settings → Pro → Apple & Google Pay from a returned Pro category; it is a configuration surface, not a customer-wallet balance screen.
These controls sit at provider, merchant/domain, credential, certificate, checkout, and payment boundaries. Source inspection does not prove any deployed dependency or effect; no verification, upload, credential access, or configuration change was performed.
Fixed API catalogue and Dashboard boundary
The fixed API catalogue defines pro_payments children global_apple_pay and global_google_pay with the configuration keys below. The accepted Dashboard source still renders Pro categories from project-returned data, so the catalogue does not establish a returned or deployed Apple & Google Pay category, provider, or configured value.
The fixed API catalogue and preserved capture record these wallet credential pairs:
| Wallet | Mode control | Live pair | Sandbox pair |
|---|---|---|---|
| Apple Pay | global_apple_pay_sandbox | global_apple_pay_publishable, global_apple_pay_secret | global_apple_pay_publishable_sandbox, global_apple_pay_secret_sandbox |
| Google Pay | global_google_pay_sandbox | global_google_pay_publishable, global_google_pay_secret | global_google_pay_publishable_sandbox, global_google_pay_secret_sandbox |
The fixed source contains Business payment-method availability checks that require all four recorded values for the corresponding wallet. That expression does not validate a provider account, merchant, domain, certificate, credential, checkout, payment authorization, or wallet value.
Sequential-write boundary
The shared SettingsList controller stages changed configs and, after Save, calls the config-item save path sequentially. An earlier item can complete before a later error; the source does not implement an atomic rollback for the sequence. No field was read or changed and no provider or checkout was contacted.
Source-only boundaries
/all-settingsis level-0 routed; the Pro group additionally depends on Pro or Enterprise plan state and a returned category.- Fixed API source declares config collection/item contracts, but route presence and verbs are not runtime, authorization, persistence, provider, payment, or success evidence.
- Credential values, merchant/domain material, certificates, provider identifiers, redirect URLs, payments, and wallet value remain excluded.
- The retained screenshot shows empty credential fields; it is not evidence of current configuration.
- Re-entry requires an immutable serving receipt and an approved credential-free synthetic fixture with config writes and all provider/payment egress intercepted.
Related guides: Online payments · Pro settings