Cash App Pay integration skill. Accept payments via Cash App — the #1 personal finance app in the U.S. Covers the Network API, Customer Request API, Manageme...
---
name: cashapp-pay
version: 1.4.0
updated: 2026-03-04
description: "Cash App Pay integration skill. Accept payments via Cash App — the #1 personal finance app in the U.S. Covers the Network API, Customer Request API, Management API, Pay Kit SDK, sandbox testing, webhooks, and dispute handling."
homepage: https://developers.cash.app
api_base: https://api.cash.app
credentials: [CASHAPP_CLIENT_ID, CASHAPP_API_KEY]
metadata: {"openclaw":{"requires":{"env":["CASHAPP_CLIENT_ID","CASHAPP_API_KEY"]},"primaryEnv":"CASHAPP_API_KEY"}}
---
# Cash App Pay — Accept Payments from Cash App
Cash App Pay is a checkout solution by Block, Inc. that lets U.S. consumers pay
directly from their Cash App balance, linked bank account, or card. It eliminates
manual card entry and is optimized for mobile-first commerce.
Cash App is the **#1 personal finance app in the U.S.** by monthly active users.
Cash App Pay is available for e-commerce (web and mobile) and point-of-sale (POS)
integrations.
**Developer Docs:** [developers.cash.app](https://developers.cash.app)
**Production Base URL:** `https://api.cash.app`
**Sandbox Base URL:** `https://sandbox.api.cash.app`
---
## Architecture Overview
Cash App Pay integrations have two components:
```
┌─────────────────────────────────────────────────┐
│ FRONT END │
│ Pay Kit SDK (Web / iOS / Android) │
│ - Renders QR code (desktop) or redirect (mobile)│
│ - Handles customer authentication flow │
│ - Uses Customer Request API under the hood │
└───────────────────────┬─────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ BACK END │
│ Network API — Payments, merchants, disputes │
│ Management API — Credentials, webhooks, keys │
│ Batch Reporting — Settlements, dispute reports │
│ (All server-side only — never call from browser)│
└─────────────────────────────────────────────────┘
```
---
## APIs
### Customer Request API (Client-side)
Handles linking a customer to a merchant. This is what Pay Kit uses under the hood.
Can also be called directly for API-only integrations.
| Method | Endpoint | Description |
|--------|----------|-------------|
| POST | `/customer-request/v1/requests` | Create a customer request |
| GET | `/customer-request/v1/requests/{id}` | Retrieve a customer request (poll for status) |
**Actions** (specify one or more per request):
| Action | Description |
|--------|-------------|
| `ONE_TIME_PAYMENT` | Single payment |
| `ON_FILE_PAYMENT` | Store payment method for future charges |
| `LINK_ACCOUNT` | Link customer's Cash App account |
**Channels** (specify exactly one):
| Channel | Use Case |
|---------|----------|
| `ONLINE` | E-commerce web checkout |
| `IN_APP` | Mobile app checkout |
| `IN_PERSON` | Point-of-sale devices |
**Authorization flow:**
1. Create a customer request → receive `auth_flow_triggers` (QR code URL, mobile URL, desktop URL)
2. Customer scans QR code (desktop) or is redirected to Cash App (mobile) to approve
3. Poll the request (1x/sec recommended) or use webhooks (`customer_request.state.updated`)
4. When state = `approved`, save the `grant_id` from the `grants` array
5. Use the `grant_id` to create a payment via the Network API
QR codes **rotate every 30 seconds** and **expire every 60 seconds** — always
fetch the latest from the polling response.
### Network API (Server-side)
Server-to-server API for core payment operations. All requests must be **signed**
(see Signatures section below).
| Method | Endpoint | Description |
|--------|----------|-------------|
| POST | `/network/v1/brands` | Create a brand |
| GET | `/network/v1/brands` | List brands |
| POST | `/network/v1/merchants` | Create a merchant under a brand |
| GET | `/network/v1/merchants/{id}` | Retrieve a merchant |
| POST | `/network/v1/payments` | Create a payment |
| GET | `/network/v1/payments/{id}` | Retrieve a payment |
| POST | `/network/v1/payments/{id}/void` | Void a payment |
| POST | `/network/v1/payments/{id}/capture` | Capture a payment |
| POST | `/network/v1/refunds` | Create a refund |
| GET | `/network/v1/refunds/{id}` | Retrieve a refund |
| POST | `/network/v1/refunds/{id}/void` | Void a refund |
| GET | `/network/v1/disputes` | List disputes |
| POST | `/network/v1/disputes/{id}/evidence` | Submit dispute evidence (text or file) |
**Required headers:**
- `Authorization: <api_creds>`
- `Content-Type: application/json`
- `Accept: application/json`
- `X-Region: PDX`
- `X-Signature: <signature>` (or `sandbox:skip-signature-check` in sandbox)
**Idempotency:** All write operations require an `idempotency_key` (UUID) in the
request body to prevent duplicate operations.
### Management API (Server-side)
Automates integration management:
- Secure credential rotation
- Webhook subscription management
- Creating scoped API keys (for microservices with least-privilege access)
---
## Quick Start — API Integration
### Step 1: Create a Brand and Merchant
```bash
# Create a brand
curl -X POST https://sandbox.api.cash.app/network/v1/brands \
-H "Authorization: {{api_creds}}" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "X-Region: PDX" \
-d '{
"brand": {
"name": "My Store",
"reference_id": "external-id"
},
"idempotency_key": "unique-uuid-here"
}'
# Create a merchant under the brand
curl -X POST https://sandbox.api.cash.app/network/v1/merchants \
-H "Authorization: {{api_creds}}" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "X-Region: PDX" \
-d '{
"merchant": {
"name": "My Store - Main",
"brand_id": "BRAND_xxxxx",
"address": {
"address_line_1": "1 Market Street",
"locality": "San Francisco",
"administrative_district_level_1": "CA",
"postal_code": "94105",
"country": "US"
},
"country": "US",
"currency": "USD",
"category": "5500",
"reference_id": "external-id"
},
"idempotency_key": "unique-uuid-here"
}'
```
### Step 2: Create a Customer Request
```bash
curl -X POST https://sandbox.api.cash.app/customer-request/v1/requests \
-H "Authorization: Client {{client_id}}" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{
"request": {
"actions": [
{
"type": "ONE_TIME_PAYMENT",
"amount": 1234,
"currency": "USD",
"scope_id": "{{merchant_id}}"
}
],
"channel": "ONLINE",
"reference_id": "order-12345"
},
"idempotency_key": "unique-uuid-here"
}'
```
The response contains `auth_flow_triggers` with QR code URL, mobile URL, and
desktop URL. Poll the retrieve endpoint until `state` = `approved`, then save the
`grant_id`.
### Step 3: Create a Payment
```bash
curl -X POST https://sandbox.api.cash.app/network/v1/payments \
-H "Authorization: {{api_creds}}" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "X-Region: PDX" \
-d '{
"payment": {
"amount": 1234,
"currency": "USD",
"merchant_id": "{{merchant_id}}",
"grant_id": "{{grant_id}}",
"capture": true,
"reference_id": "order-12345"
},
"idempotency_key": "unique-uuid-here"
}'
```
Set `"capture": false` for auth-only, then capture later via the capture endpoint.
---
## Pay Kit SDK (Front End)
Pay Kit is Cash App's JavaScript SDK for embedding payment UI. It handles the
Customer Request flow automatically.
| Platform | Resources |
|----------|-----------|
| **Web** | [Pay Kit Web Guide](https://developers.cash.app/cash-app-pay-partner-api/guides/pay-kit-sdk/pay-kit-web-overview/getting-started) |
| **iOS** | [Pay Kit iOS Guide](https://developers.cash.app/cash-app-pay-partner-api/guides/pay-kit-sdk/pay-kit-i-os) |
| **Android** | [Pay Kit Android Guide](https://developers.cash.app/cash-app-pay-partner-api/guides/pay-kit-sdk/pay-kit-android) |
Pay Kit adapts to the user's device:
- **Desktop** → Displays a QR code for scanning with Cash App
- **Mobile** → Redirects to Cash App for authentication, then back to merchant
For advanced control over when and how the authorization flow starts, use Pay Kit's
**advanced controls** mode.
---
## Webhooks
Subscribe to webhook events for real-time updates instead of polling.
| Event | Trigger |
|-------|---------|
| `customer_request.state.updated` | Customer request state changes (approved, declined, etc.) |
Webhook subscriptions are managed through the Management API. There is **no webhook
event for QR code rotation** — use polling or check the `refreshes_at` timestamp
to fetch the latest QR code.
---
## Sandbox
Cash App provides a full sandbox environment for testing without moving real money.
| Item | Value |
|------|-------|
| **Sandbox host** | `sandbox.api.cash.app` |
| **Sandbox App** | Available for testing customer approval flows |
| **Sandbox Web** | Web-based approval simulator |
| **Credentials** | Separate from production — obtain from Cash App Partner Engineering |
| **Signature bypass** | Set `X-Signature: sandbox:skip-signature-check` |
| **Backwards compatibility** | 5-year guarantee on sandbox magic values |
### Magic Values (Payment Amounts)
Use these amounts in the `amount` field to trigger specific outcomes:
| Amount | Result |
|--------|--------|
| `6670` | Connection error (HTTP error returned, payment still created) |
| `7770` | Decline: compliance failure |
| `7771` | Decline: insufficient funds |
| `7772` | Decline: other |
| `7773` | Decline: risk |
| `7774` | Decline: amount too large |
| `7775` | Decline: amount too small |
| `8801` | Creates payment + dispute (reason CD10) |
| `8802` | Creates payment + dispute (reason CD11) |
| `8803` | Creates payment + dispute (reason CD12) |
| `8804` | Creates payment + dispute (reason CD13) |
| `8811` | Creates payment + dispute (reason FR10 — fraud) |
| `8812` | Creates payment + dispute (reason FR11 — fraud) |
| `8821`–`8823` | Creates payment + dispute (PE10–PE12 — processing error) |
| `8901` | Creates payment + dispute with differing disputed amount |
### Magic Grant IDs
| Grant ID | Result |
|----------|--------|
| `GRG_sandbox:active` | Payment created successfully |
| `GRG_sandbox:consumed` | Decline: grant consumed |
| `GRG_sandbox:expired` | Decline: grant expired |
| `GRG_sandbox:missing` | Decline: grant not found |
| `GRG_sandbox:revoked` | Decline: grant revoked |
### Magic Merchant IDs
| Merchant ID | Result |
|-------------|--------|
| `MMI_sandbox:disabled` | Error: merchant disabled |
| `MMI_sandbox:pending` | Error: merchant pending |
| `MMI_sandbox:missing` | Error: merchant not found |
---
## Request Signatures
All Network API and Management API requests must be **signed** in production.
Signatures are provided via the `X-Signature` header.
In sandbox, bypass signing by setting:
```
X-Signature: sandbox:skip-signature-check
```
For production signing implementation details, see the
[Making Requests](https://developers.cash.app/cash-app-pay-partner-api/guides/technical-guides/api-fundamentals/requests/making-requests)
documentation.
---
## Settlements & Disputes
### Settlements
Cash App uses **net settlement** — refund and dispute amounts are deducted from
settlement payouts. Reconciliation reports are uploaded **daily** via SFTP to a
PSP-hosted server, regardless of whether there was payment activity.
### Disputes
Dispute reports are also uploaded daily via SFTP. Use the Network API's dispute
endpoints to retrieve dispute details and submit evidence (text or file-based).
**Dispute evidence magic values** (sandbox):
| Metadata Value | Result |
|----------------|--------|
| `{"sandbox:set_dispute_state": "PROCESSING"}` | Dispute moves to PROCESSING |
| `{"sandbox:set_dispute_state": "WON"}` | Dispute resolved — won |
| `{"sandbox:set_dispute_state": "PARTIALLY_WON"}` | Dispute resolved — partially won |
| `{"sandbox:set_dispute_state": "LOST"}` | Dispute resolved — lost |
---
## Integration Paths
| Path | Best For | Docs |
|------|----------|------|
| **Cash App Afterpay (Sellers)** | Merchants adding Cash App Pay or Afterpay to their checkout | [Seller Docs](https://developers.cash.app/cash-app-afterpay/guides/welcome/getting-started) |
| **Cash App Pay Partner API (PSPs)** | Payment service providers building platform-level integrations | [PSP Docs](https://developers.cash.app/cash-app-pay-partner-api/guides/welcome) |
---
## Resources
| Resource | URL |
|----------|-----|
| Developer Documentation | [developers.cash.app](https://developers.cash.app) |
| API Reference (Network) | [Network API Reference](https://developers.cash.app/cash-app-pay-partner-api/api-reference/network-api/list-brands) |
| Cash App Pay Status | [Status Page](https://developers.cash.app/cash-app-pay-partner-api/guides/resources/cash-app-pay-status) |
| Brand Assets | [Cash App Pay Assets](https://developers.cash.app/cash-app-pay-partner-api/guides/resources/cash-app-pay-assets) |
| Glossary | [Glossary of Terms](https://developers.cash.app/cash-app-pay-partner-api/guides/resources/glossary-of-terms) |
| Postman Collection | [Postman Collection](https://developers.cash.app/cash-app-pay-partner-api/guides/technical-guides/sandbox/postman-collection) |
---
## Important Notes
- **Cash App Pay is U.S. only.** Both merchants and customers must be in the United
States. Currency is USD.
- **All Network/Management API requests must be signed in production.** Use the
`X-Signature` header. In sandbox, set it to `sandbox:skip-signature-check`.
- **All write operations require an idempotency key.** Use a unique UUID for each
request to prevent duplicate charges, refunds, or merchant registrations.
- **QR codes rotate every 30 seconds and expire every 60 seconds.** Always fetch
the latest from polling responses. Do not cache QR code URLs.
- **Sandbox credentials are separate from production.** Never use production
credentials in the sandbox or vice versa.
- **Partner onboarding requires approval.** Contact the Cash App Pay Partner
Engineering team to confirm the right integration path and obtain API credentials.
- **Never expose API credentials client-side.** The Network API and Management API
are server-side only. Only the Customer Request API and Pay Kit SDK are used on
the client.
- **Cash App Pay is a product of Block, Inc.** (formerly Square, Inc.). It is not
affiliated with CreditClaw.
don't have the plugin yet? install it then click "run inline in claude" again.
added explicit intent, reorganized procedure into 7 discrete steps with clear inputs/outputs, extracted all decision points (device type, state checks, error handling, integration path) into a dedicated section, added edge cases (rate limits, auth expiry, qr rotation, network timeouts, signature requirements), expanded output contract with success criteria and data format, and added outcome signal checklist showing how user knows each step succeeded.
this skill integrates cash app pay into your payment system to accept u.s.-only payments directly from cash app balances, linked bank accounts, or cards. use this when you need a checkout solution optimized for mobile-first commerce with no manual card entry friction. cash app is the number one personal finance app in the u.s. by monthly active users. the skill covers both front-end ui (pay kit sdk for web, ios, android) and back-end apis (network api for payments, customer request api for authentication, management api for credential and webhook lifecycle).
environment variables / secrets:
CASHAPP_CLIENT_ID (string, required): client id for customer request api. obtained from cash app partner engineering during onboarding.CASHAPP_API_KEY (string, required): api key for network api and management api. never expose this client-side. obtained from cash app partner engineering during onboarding.external connections:
context / existing data required:
merchant_id (string): cash app merchant id created via the network api brands and merchants endpoints. required for all payments.brand_id (string): cash app brand id created via the network api. required to create merchants.grant_id (string): authorization grant from an approved customer request. required to create a payment.customer_request_id (string): id of the customer request. used to poll for approval status or subscribe to webhook events.device/platform context:
input: your store name, address, mcc category code (e.g. 5500 for general merchandise), reference id (your internal identifier).
POST /network/v1/brands with your brand name, reference id, and idempotency key (uuid).brand_id.POST /network/v1/merchants with the brand_id, merchant name, full address, country (us only), currency (usd), category, reference id, and idempotency key.merchant_id.output: brand_id (string), merchant_id (string). store these in your database.
note: idempotency keys prevent duplicate brand/merchant creation if you retry. always use a new uuid per request.
input: merchant_id, payment amount (integer, cents), channel (online, in_app, or in_person), action type (one_time_payment, on_file_payment, or link_account), reference id (your order id), idempotency key (uuid).
POST /customer-request/v1/requests with authorization header Client {{client_id}} (not the api key).customer_request_id and auth_flow_triggers object (contains qr_code_url, mobile_url, desktop_url).auth_flow_triggers.qr_code_url (refreshes every 30 seconds, expires every 60 seconds).auth_flow_triggers.mobile_url.auth_flow_triggers.in_person_url or display on pos terminal.output: customer_request_id (string), auth_flow_triggers object (qr_code_url, mobile_url, desktop_url, expires_at, refreshes_at).
note: qr codes rotate every 30 seconds and expire every 60 seconds. always fetch fresh from polling or webhook to avoid expired codes. do not cache qr code urls.
input: customer_request_id.
option a (polling):
GET /customer-request/v1/requests/{{customer_request_id}} every 1 second (or subscribe to webhook instead).state field in the response.approved, extract grant_id from the grants array and go to step 4.declined or expired, show error to customer and return to step 2.pending, continue polling (timeout after 10 minutes).option b (webhooks):
customer_request.state.updated events via management api (see resources).approved, extract grant_id from payload and go to step 4.declined or expired, handle error.output: grant_id (string, from grants[0].grant_id), state (string: approved, declined, expired, or pending).
note: polling requires 1 request per second and may hit rate limits. webhooks are recommended for production.
input: merchant_id, grant_id, amount (integer, cents), currency (usd), idempotency key (uuid), capture flag (true for auth-and-capture, false for auth-only), reference id (order id).
POST /network/v1/payments with headers:Authorization: {{api_creds}} (use CASHAPP_API_KEY)Content-Type: application/jsonAccept: application/jsonX-Region: PDXX-Signature: <computed_signature> (production only; sandbox: sandbox:skip-signature-check)payment_id, state, amount, created_at.approved, payment succeeded.declined, return decline reason to customer and return to step 2.error, log and retry with new idempotency key after 5 seconds (one retry max).output: payment_id (string), state (string: approved, declined, error, voided, or captured), amount (integer), created_at (iso8601 timestamp).
note: all network api requests must be signed in production. signatures prevent tampering. in sandbox, bypass with X-Signature: sandbox:skip-signature-check. see cash app docs for signature algorithm details.
input: payment_id (from step 4, if capture was false).
POST /network/v1/payments/{{payment_id}}/capture with idempotency key and signature header.captured).output: payment_id, state (captured).
to void a payment (before capture or after):
POST /network/v1/payments/{{payment_id}}/void with idempotency key and signature.voided.to refund (after capture):
POST /network/v1/refunds with payment_id, amount, currency, reference_id, and idempotency key.refund_id, state.output: payment_id or refund_id, state (voided or refund_approved).
input: payment_id with a dispute attached (returned in payment details or via daily dispute sftp report).
GET /network/v1/disputes to list active disputes.dispute_id, reason (e.g. cd10, fr10), amount, state (open, processing, won, lost).POST /network/v1/disputes/{{dispute_id}}/evidence with evidence_type, text, and metadata.processing after submission.output: dispute_id, state (processing, won, lost, partially_won).
if device is desktop (web checkout):
auth_flow_triggers.qr_code_url. customer scans with cash app. customer approves in cash app. go to step 3 (polling or webhook).if device is mobile (app or mobile web):
auth_flow_triggers.mobile_url. cash app opens. customer approves. cash app redirects back to your app. go to step 3.if device is in-person (pos terminal):
if customer request state is approved:
if customer request state is declined or expired:
if payment state is approved:
if payment state is declined:
if payment state is error (connection error or timeout):
if using auth-only (capture=false):
if payment is disputed:
GET /network/v1/disputes or monitor sftp dispute report. decide whether to submit evidence (step 7) or accept the chargeback. evidence can improve win rate.if integrating as a psp (multi-merchant platform):
if integrating as a seller (direct merchant):
if rate limited:
if api credentials expire or are rotated:
if webhook delivery fails:
if settling disputes in sandbox:
{"sandbox:set_dispute_state": "WON"}) to transition dispute state for testing without waiting for manual review.success criteria:
brand_id and merchant_id stored in database. merchant is active and ready to receive payments.customer_request_id and auth_flow_triggers returned. qr code or redirect url is valid and displays to customer.grant_id extracted from approved request. grant is valid and not consumed, expired, or revoked.payment_id created. payment state is approved and amount is deducted from customer's cash app balance (or linked account). payment_id is idempotent (retrying with same idempotency key returns same payment_id).approved to captured.refund_approved. amount is credited back to customer within 1-3 business days.processing after evidence submission.data format (json):
all responses are json objects with root keys: id, created_at, type, and type-specific fields (e.g. payment → amount, currency, merchant_id, state).
file locations / storage:
idempotency: all write operations (brand, merchant, payment, refund, void) are idempotent. retrying with the same idempotency_key returns the same resource without creating duplicates.
the user knows the skill worked when:
brand and merchant created: POST /network/v1/brands and POST /network/v1/merchants both return http 201 with brand_id and merchant_id in the response. you can see the merchant in cash app partner dashboard.
customer request created: POST /customer-request/v1/requests returns http 201 with a valid qr code url or mobile redirect url. customer can scan or tap without errors.
customer approved: polling GET /customer-request/v1/requests/{{id}} returns state approved with a valid grant_id. webhook event customer_request.state.updated fires (if subscribed).
payment created: POST /network/v1/payments returns http 201 with payment state approved. amount appears in your settlement report 24 hours later. customer sees the charge in their cash app transaction history.
payment captured (if auth-only): POST /network/v1/payments/{{id}}/capture returns http 200 with state captured. amount is now final and will settle.
refund created: POST /network/v1/refunds returns http 201 with state refund_approved. customer sees credit in cash app within 1-3 business days.
dispute evidence submitted: POST /network/v1/disputes/{{id}}/evidence returns http 200. dispute state transitions to processing. cash app reviews and resolves within 7-10 days.
settlement received: daily sftp report shows net settlement amount (gross payments minus refunds and disputes) deposited to your bank account. reconciliation matches your transaction log.
in sandbox, all requests behave identically to production except signatures are optional. set X-Signature: sandbox:skip-signature-check and credentials are separate from production.
magic payment amounts (trigger specific outcomes in sandbox):
| amount (cents) | result |
|---|---|
| 6670 | connection error returned, but payment still created (tests error handling) |
| 7770 | decline: compliance failure |
| 7771 | decline: insufficient funds |
| 7772 | decline: other |
| 7773 | decline: risk |
| 7774 | decline: amount too large |
| 7775 | decline: amount too small |
| 8801-8804, 8811-8812, 8821-8823, 8901 | payment created plus dispute with specific reason code (tests dispute flow) |
magic grant ids (simulate customer request outcomes):
| grant id | result |
|---|---|
GRG_sandbox:active |
payment succeeds |
GRG_sandbox:consumed |
decline: grant already used |
GRG_sandbox:expired |
decline: grant expired |
GRG_sandbox:missing |
decline: grant not found |
GRG_sandbox:revoked |
decline: grant revoked by customer |
magic merchant ids (simulate merchant errors):
| merchant id | result |
|---|---|
MMI_sandbox:disabled |
error: merchant is disabled |
MMI_sandbox:pending |
error: merchant onboarding pending |
MMI_sandbox:missing |
error: merchant not found |
magic dispute metadata (transition dispute state in sandbox):
| metadata key | value | result |
|---|---|---|
sandbox:set_dispute_state |
PROCESSING |
dispute moves to processing state |
sandbox:set_dispute_state |
WON |
dispute resolved, you won |
sandbox:set_dispute_state |
PARTIALLY_WON |
dispute partially resolved in your favor |
sandbox:set_dispute_state |
LOST |
dispute lost |
pay kit is cash app's sdk for embedding payment ui without building custom auth flows. it handles customer request creation and polling under the hood.
platforms:
behavior:
advanced mode: pay kit also supports fine-grained control over when auth flow starts (e.g. "show button, on click open flow"). see cash app pay kit docs for implementation.
after customer approves via pay kit, your backend receives the grant_id and proceeds to step 4 (create payment).
rate limits:
auth expiry:
empty result sets:
GET /network/v1/disputes may return empty list if no active disputes. this is normal.GET /network/v1/payments/{{id}} with invalid payment_id returns 404. always validate payment_id before lookup.network timeouts:
qr code rotation and expiry:
refreshes_at timestamp in polling response). qr codes expire every 60 seconds (expires_at timestamp). always fetch fresh from polling, do not cache urls.declined or expired grants:
signature verification in production:
X-Signature header in production. signing algorithm is hmac-sha256. see cash app docs for details. failure to sign results in 401 unauthorized.idempotency key uniqueness:
u.s. only:
settlement timing:
webhook retry logic:
note: cash app pay is a block, inc. product (formerly square). it is not affiliated with implexa or clawhub. partner onboarding requires approval from cash app partner engineering team. sandbox credentials are separate from production. never use production credentials in sandbox or vice versa.