Coinbase Commerce migration

# Migrate Coinbase Commerce to MakePay

Use this as the working brief for an AI coding agent. Replace Coinbase Commerce charge creation, charge webhook verification, timeline/status reconciliation, metadata mapping, and provider SDK/API usage with MakePay payment links, signed webhooks, and the SDK that matches the codebase.

## Target MakePay SDK

Choose one install command for the stack being migrated:

```bash
npm install @makecrypto/makepay
composer require makepay/makepay-php
go get github.com/makecryptoio/makepay-go
pip install makepay
cargo add makepay
```

For JVM services use:

```kotlin
implementation("io.makecrypto:makepay:0.1.0")
```

For Swift Package Manager use:

```swift
.package(url: "https://github.com/makecryptoio/makepay-swift-sdk.git", from: "0.3.0")
```

## Migration map

- Coinbase Commerce `POST https://api.commerce.coinbase.com/charges` charge creation -> MakePay `POST /api/partner/v1/makepay/payment-links` or the SDK create-payment-link helper.
- Coinbase Commerce `hosted_url` -> MakePay `paymentLink.publicUrl`.
- Coinbase Commerce charge `id` or `code` -> MakePay `paymentLink.uid`; keep the old charge ID/code in a migration alias table while orders are in flight.
- Coinbase Commerce `name` and `description` -> MakePay `label` and `description`.
- Coinbase Commerce `pricing_type: fixed_price` plus `local_price.amount` and `local_price.currency` -> MakePay `payload.amount` and `payload.currency` or exact `payload.asset`.
- Coinbase Commerce `metadata.order_id` and related metadata -> MakePay `merchantOrderId` plus internal metadata.
- Coinbase Commerce `redirect_url` and `cancel_url` -> MakePay success/failure redirect settings or hosted-page return handling.
- Coinbase Commerce `X-CC-Api-Key` -> MakePay `X-MakeCrypto-Key-Id` and `X-MakeCrypto-Key-Secret` headers.
- Coinbase Commerce `X-CC-Webhook-Signature` HMAC verification -> MakePay `x-makepay-signature` HMAC verification over the raw request body.
- Coinbase Commerce events `charge:created`, `charge:pending`, `charge:confirmed`, and `charge:failed` plus timeline statuses `NEW`, `SIGNED`, `PENDING`, `COMPLETED`, `EXPIRED`, and `FAILED` -> MakePay `makepay.payment.status_changed` events and normalized order states.

## Agent prompt: inventory

You are migrating this repository from Coinbase Commerce to MakePay. Search for Coinbase Commerce SDK/API clients, `api.commerce.coinbase.com`, `/charges`, `X-CC-Api-Key`, `X-CC-Webhook-Signature`, `hosted_url`, charge `id`, charge `code`, `pricing_type`, `local_price`, `redirect_url`, `cancel_url`, `metadata`, webhook handlers, and event/status handling for `charge:created`, `charge:pending`, `charge:confirmed`, `charge:failed`, `NEW`, `SIGNED`, `PENDING`, `COMPLETED`, `EXPIRED`, and `FAILED`. Return a file-by-file migration plan with the exact functions that create charges, store provider IDs/codes, redirect buyers, verify webhooks, inspect charge timelines, and reconcile order status. Do not edit files yet.

## Agent prompt: replace charge creation

Implement MakePay payment-link creation in the existing Coinbase Commerce charge creation path. Use the official MakePay SDK for this stack when available; otherwise call `POST /api/partner/v1/makepay/payment-links`. Map `local_price.amount` to `payload.amount`, `local_price.currency` to `payload.currency` or `payload.asset`, `metadata.order_id` to `merchantOrderId`, and `name`/`description` to `label`/`description`. Store `paymentLink.uid` and `paymentLink.publicUrl`, and keep nullable legacy Coinbase Commerce charge ID/code fields for historical records.

## Agent prompt: replace webhook verification

Replace Coinbase Commerce webhook verification with MakePay webhook verification. For legacy Coinbase Commerce orders, keep `X-CC-Webhook-Signature` verification and status reconciliation until open charges are closed. For new MakePay events, read the exact raw request body before JSON parsing, parse `x-makepay-signature`, verify timestamp tolerance and HMAC digest with the MakePay webhook secret, then process only trusted events. Treat `makepay.payment.status_changed` as the primary order reconciliation event and make updates idempotent by delivery ID and payment-link UID.

## Agent prompt: normalize statuses

Map legacy Coinbase Commerce statuses explicitly during cutover. `charge:created`, `NEW`, and `SIGNED` should not grant goods. `charge:pending` and `PENDING` should not grant goods by default. `charge:confirmed` or `COMPLETED` can complete the order. `charge:failed`, `FAILED`, and `EXPIRED` should close the legacy payment without marking the order paid.

## Agent prompt: dual-run cutover

Add a migration flag so newly created orders use MakePay while existing Coinbase Commerce charges can still receive webhooks until they are confirmed, failed, or expired. Route callbacks by provider, keep provider-specific IDs separate, and add logs that include provider, order ID, payment UID, delivery ID, legacy charge ID/code, and normalized status. Remove Coinbase Commerce credentials and webhook secret only after there are no open legacy charges.

## Agent prompt: tests

Add or update tests for MakePay payment-link creation, failed authentication, webhook signature rejection, successful `makepay.payment.status_changed` handling, duplicate webhook delivery idempotency, legacy Coinbase Commerce webhook routing during cutover, pending not granting goods, confirmed/completed handling, failed/expired handling, webhook signature rejection, and buyer redirect URL generation. Use mocked MakePay SDK/API responses; do not hit production APIs in tests.

## Verification checklist

- A new order creates exactly one MakePay payment link and stores `paymentLink.uid`.
- The buyer redirect uses `paymentLink.publicUrl` instead of Coinbase Commerce `hosted_url`.
- Webhook verification fails closed when `x-makepay-signature` is missing, stale, or invalid.
- Webhooks are idempotent by delivery ID and cannot regress a completed order.
- Legacy Coinbase Commerce webhooks keep `X-CC-Webhook-Signature` verification until cutover is complete.
- Legacy created/pending/confirmed/failed/expired paths are explicitly tested.
- Existing Coinbase Commerce charges remain reconcilable until the migration flag is fully removed.