{"skill":{"slug":"google-pay","displayName":"Google Pay","summary":"Implement Google Pay for web and Android with tokenization safety, gateway alignment, and production-ready checkout operations.","description":"---\nname: Google Pay\nslug: google-pay\nversion: 1.0.0\nhomepage: https://clawic.com/skills/google-pay\ndescription: Implement Google Pay for web and Android with tokenization safety, gateway alignment, and production-ready checkout operations.\nchangelog: Initial release with implementation, validation, launch, and incident response playbooks for Google Pay.\nmetadata: {\"clawdbot\":{\"emoji\":\"💳\",\"requires\":{\"bins\":[\"curl\",\"jq\"],\"env\":[\"GOOGLE_PAY_MERCHANT_ID\"]},\"os\":[\"darwin\",\"linux\",\"win32\"]}}\n---\n\n## Setup\n\nOn first use, read `setup.md` and confirm platform, PSP, and release target before making code changes.\n\n## When to Use\n\nUser needs Google Pay in checkout, subscriptions, or wallet-first conversion flows. Agent handles architecture decisions, tokenization mode, gateway integration, rollout validation, and post-launch operations.\n\n## Architecture\n\nMemory lives in `~/google-pay/`. See `memory-template.md` for setup and status fields.\n\n```\n~/google-pay/\n|-- memory.md                 # Project snapshot, risk status, and rollout state\n|-- implementations.md        # Selected approach and platform notes\n|-- validation-log.md         # Test evidence and environment results\n`-- incidents.md              # Failed payments, root causes, and fixes\n```\n\n## Quick Reference\n\nUse the smallest relevant file for the current task.\n\n| Topic | File |\n|-------|------|\n| Setup flow | `setup.md` |\n| Memory template | `memory-template.md` |\n| Implementation plan | `implementation-playbook.md` |\n| Validation matrix | `validation-checklist.md` |\n| Failure recovery | `failure-handling.md` |\n| Release and operations | `launch-playbook.md` |\n| Recurring and subscription flows | `recurring-payments.md` |\n\n## Requirements\n\n- Environment variable: `GOOGLE_PAY_MERCHANT_ID`\n- CLI tools for diagnostics: `curl`, `jq`\n- Access to Google Pay business console and target PSP account\n\nNever ask users to paste private keys, full token payloads, or PSP secrets into chat.\n\n## Data Storage\n\nLocal notes stay under `~/google-pay/`:\n- memory file for current state and integration decisions\n- validation log file for test outcomes and evidence\n- incidents file for failure signatures and mitigations\n\n## Core Rules\n\n### 1. Confirm Business Goal Before Choosing Integration Path\nStart by identifying the target outcome:\n- Higher mobile checkout conversion\n- Faster repeat purchases\n- Lower payment friction on Android and Chrome\n- Fewer payment failures\n\nThen choose one primary path:\n- Web with Google Pay API and gateway tokenization\n- Android with Google Pay API in app flow\n- PSP-mediated integration path\n\nDo not mix paths in one patch unless the user asks for a migration plan.\n\n### 2. Require Environment and Merchant Prerequisites\nBefore implementation, confirm:\n- Google Pay merchant profile exists for production\n- Gateway or PSP supports Google Pay in target countries\n- Test environment is isolated from production\n- Origin and app package configuration are correct\n\nIf prerequisites are missing, pause coding and produce a concrete prerequisite checklist.\n\n### 3. Enforce Server Truth for Amounts and Currency\nAmounts and currency must match across:\n- Client payment data request\n- Server-side cart or order totals\n- PSP authorization and capture calls\n\nNever trust client totals for final charge amount.\n\n### 4. Keep Token Handling Minimal and Auditable\nTreat Google Pay token payloads as sensitive:\n- Forward payload only to backend or PSP\n- Persist metadata only (request id, status, amount, currency)\n- Never store raw token payload in logs, notes, or screenshots\n\n### 5. Choose Tokenization Path Explicitly\nUse one clear tokenization mode per project:\n- `PAYMENT_GATEWAY` for most integrations\n- `DIRECT` only when user explicitly owns decryption and PCI scope\n\nDo not mix tokenization modes without a documented migration and risk review.\n\n### 6. Build Idempotent and Recoverable Payment Steps\nRequire idempotency and reconciliation for all critical calls:\n- Authorization request\n- Capture request\n- Refund or void operations\n\nEvery retried request must reuse stable idempotency keys to prevent duplicates.\n\n### 7. Separate Test and Production Release Gates\nDo not recommend production rollout until all gates pass:\n- Test success, decline, cancellation, and timeout paths are covered\n- Device and browser matrix is complete for supported audience\n- Fallback card or alternative checkout works when Google Pay is unavailable\n- Failure observability and alerts are active\n\n## Common Traps\n\n- Shipping test environment config to production -> checkout fails for live users\n- Mismatching gateway merchant ids across environments -> token processing errors\n- Skipping `isReadyToPay` style capability checks -> broken wallet button behavior\n- Trusting client totals -> mismatch between authorized and captured amounts\n- Missing idempotency on retries -> duplicate charges and refund overhead\n- Launching without fallback checkout -> conversion loss when wallet is unavailable\n\n## External Endpoints\n\n| Endpoint | Data Sent | Purpose |\n|----------|-----------|---------|\n| https://pay.google.com | Payment request and wallet flow payloads | Google Pay wallet interactions and client integration |\n| https://pay.google.com/gp/p/js/pay.js | Script request metadata | Load Google Pay JavaScript client library |\n| https://payments.developers.google.com | Documentation fetch traffic | Reference integration docs and test cards |\n\nNo other data should be sent externally unless the selected PSP requires it.\n\n## Security & Privacy\n\nData that leaves your machine:\n- Google Pay request payloads needed for wallet flow\n- Payment token payloads sent to configured PSP or backend\n\nData that stays local:\n- Integration notes and rollout state under `~/google-pay/`\n- Validation evidence and failure logs without raw token payloads\n\nThis skill does NOT:\n- Store raw token payloads in memory files\n- Skip mandatory merchant and gateway requirements\n- Enable production release without explicit readiness checks\n\n## Trust\n\nGoogle Pay integrations depend on Google infrastructure and the chosen PSP.\nOnly install and run this skill if you trust those services and your payment backend.\n\n## Related Skills\nInstall with `clawhub install <slug>` if user confirms:\n- `payments` - General payment design and checkout decision frameworks\n- `android` - Android implementation and runtime troubleshooting patterns\n- `billing` - Billing models, reconciliation, and payment lifecycle decisions\n- `auth` - Authentication and session hardening in transaction flows\n- `api` - Reliable backend API contracts and failure-safe integrations\n\n## Feedback\n\n- If useful: `clawhub star google-pay`\n- Stay updated: `clawhub sync`\n","tags":{"latest":"1.0.0"},"stats":{"comments":0,"downloads":533,"installsAllTime":20,"installsCurrent":0,"stars":0,"versions":1},"createdAt":1772576708676,"updatedAt":1778491707669},"latestVersion":{"version":"1.0.0","createdAt":1772576708676,"changelog":"Initial release with implementation, validation, launch, and incident response playbooks for Google Pay.","license":null},"metadata":{"setup":[{"key":"GOOGLE_PAY_MERCHANT_ID","required":true}],"os":["darwin","linux","win32"],"systems":null},"owner":{"handle":"ivangdavila","userId":"s178jdk12x4qj3gs2se3etxf3h83h7ft","displayName":"Iván","image":"https://avatars.githubusercontent.com/u/81719670?v=4"},"moderation":null}