ترحيل AI

CoinsPaid migration

Use an AI agent to replace CoinsPaid invoices, deposit-address flows, HMAC signatures, callbacks, and status handling with MakePay APIs and SDKs.

Overview

This AI compatibility guide gives a senior developer or coding agent a direct path for replacing CryptoProcessing by CoinsPaid with MakePay. It covers invoice creation, hosted invoice URLs, reusable deposit-address flows, request signing, callback signature verification, transaction lookup, invoice and deposit statuses, and SDK installation.

Use it when the existing codebase calls the CryptoProcessing API directly, wraps CoinsPaid behind a payment provider abstraction, or stores CoinsPaid invoice, deposit-address, transaction, foreign_id, or end_user_reference values on orders. CoinsPaid documents the current API in Introduction, Authentication, Create an invoice, Generate a crypto address, Callbacks, and Transaction statuses.

Payment links API

Webhook verification

SDK libraries

Migration map

CoinsPaid integrations usually sign each request body with HMAC-SHA512, create a hosted invoice through POST /api/v2/invoices/create or generate reusable deposit addresses with POST /api/v2/addresses/take, redirect the buyer to the invoice response url, and process signed callbacks. In MakePay, use payment links, signed webhooks, and SDK helpers for the same order flow.

CoinsPaid surface	MakePay replacement
`X-Processing-Key` and `X-Processing-Signature`	`X-MakeCrypto-Key-Id` and `X-MakeCrypto-Key-Secret` headers or SDK credentials
HMAC-SHA512 of the exact JSON request body	SDK request signing or MakePay credential headers
`POST /api/v2/invoices/create` invoice creation	`POST /api/partner/v1/makepay/payment-links` or SDK create-payment-link helper
Invoice response `data.url`	`paymentLink.publicUrl`
Invoice response `data.id`	`paymentLink.uid`; keep a legacy alias during cutover
`foreign_id`	`merchantOrderId`
`end_user_reference`	Customer reference or internal metadata
`title` and `description`	`label` and `description`
`currency`, `amount`, and optional `sender_currency`	`payload.amount` plus `payload.currency` or exact `payload.asset`
`url_success` and `url_failed`	MakePay success/failure redirects or hosted-page return handling
`timer`, `fill_or_kill`, and `good_until_expired`	Payment-link expiry and underpayment/partial-payment business rules
`POST /api/v2/addresses/take` reusable deposit address flow	MakePay payment links for per-order checkout; keep address flow only for legacy deposits
Callback `X-Processing-Signature`	`x-makepay-signature` HMAC verification over the raw request body
Callback root `id` and transaction IDs	Webhook delivery ID plus `paymentLink.uid` for idempotency
`GET /api/v2/transactions/info` reconciliation	MakePay payment-link lookup and webhook replay/reconciliation tooling
Invoice and deposit statuses	`makepay.payment.status_changed` webhooks and normalized order states

For a clean migration, keep provider-specific IDs separate. Existing CoinsPaid invoices and deposit addresses should continue to reconcile until they are confirmed, failed, cancelled, declined, refunded, or otherwise closed by current business rules, while new orders use MakePay.

SDK install commands

Pick the SDK that matches the service being migrated. These are the same quick commands shown on the MakePay SDK cards.

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

implementation("io.makecrypto:makepay:0.3.0")

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

Use the SDK for payment-link creation and webhook verification whenever the language supports it. If a service has a custom HTTP client layer, call the payment-links API directly and keep the provider adapter small.

Agent prompts

Inventory CoinsPaid usage

You are migrating this repository from CryptoProcessing by CoinsPaid to MakePay.
Search for CoinsPaid/CryptoProcessing API clients, cryptoprocessing.com,
app.cryptoprocessing.com, app.sandbox.cryptoprocessing.com, /api/v2,
/invoices/create, /addresses/take, /transactions/info, X-Processing-Key,
X-Processing-Signature, HMAC-SHA512 signing helpers, foreign_id,
end_user_reference, sender_type, sender_data, url_success, url_failed,
email_user, timer, fill_or_kill, good_until_expired, sender_currency, invoice
response url, callback handlers, callback root id, transaction ids, txid, and
status handling for created, processing, confirmed, failed, not_confirmed,
cancelled, pending, and declined.

Return a file-by-file migration plan with the exact functions that sign
requests, create invoices, generate deposit addresses, store provider IDs,
redirect buyers, verify callbacks, fetch transaction details, and reconcile
order status. Do not edit files yet.

Replace invoice creation

Implement MakePay payment-link creation in the existing CoinsPaid invoice
creation path. Use the official MakePay SDK for this stack when available;
otherwise call POST /api/partner/v1/makepay/payment-links.

Remove X-Processing-Key/X-Processing-Signature request signing from the new-order
path. Map foreign_id to merchantOrderId, end_user_reference and sender metadata
to internal metadata, title to label, description to description, amount to
payload.amount, and currency or sender_currency to payload.currency or
payload.asset. Store paymentLink.uid and paymentLink.publicUrl, and keep
nullable legacy CoinsPaid invoice ID and foreign_id fields for historical
records.

Replace deposit-address flows

Find any CoinsPaid /addresses/take flow that generates reusable customer deposit
addresses. For one-off order checkout, replace it with MakePay payment links so
each order has a paymentLink.uid and paymentLink.publicUrl. If the product still
needs customer balance top-ups, keep the legacy address flow behind a provider
flag until all old addresses and callbacks are reconciled, then design a
MakePay-native top-up flow separately.

Replace callback verification

Replace CoinsPaid callback verification with MakePay webhook verification. For
legacy CoinsPaid invoices and deposit addresses, keep X-Processing-Signature
verification by computing a lowercase hex HMAC-SHA512 over the exact raw request
body with the CoinsPaid secret key and comparing it with a timing-safe compare.
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 status updates idempotent by delivery ID and payment-link UID. For
legacy callbacks, use callback root id plus transaction id or txid for
idempotency.

Normalize statuses

Map legacy CoinsPaid statuses explicitly during cutover. Invoice status created
should not grant goods. Invoice status processing should remain pending until a
confirmed callback arrives. Invoice status confirmed can complete the order.
Invoice status failed should close the payment without marking it paid and
preserve the error value for support.

Deposit status not_confirmed should remain pending. Deposit status confirmed can
complete balance credit or order fulfillment only after amount and currency match
the order policy. Deposit status cancelled, transaction status declined, and
known underpayment/minimum-amount/cross-currency exceptions should route to
manual review, refund, or unpaid closure according to existing business rules.

Dual-run cutover

Add a migration flag so newly created orders use MakePay while existing
CoinsPaid invoices and deposit addresses can still receive callbacks until they
are confirmed, failed, cancelled, declined, refunded, or expire through the
current business rules. Route callbacks by provider, keep provider-specific IDs
separate, and add logs that include provider, order ID, payment UID, delivery ID,
legacy invoice ID, foreign_id, end_user_reference, callback ID, transaction ID,
txid, and normalized status.

Remove CoinsPaid API credentials, HMAC-SHA512 signing helpers,
X-Processing-Signature callback verification, transaction-info polling, and
deposit-address creation code only after there are no open legacy invoices,
addresses, or pending callbacks.

Write 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 CoinsPaid callback routing during
cutover, CoinsPaid HMAC rejection, created and processing not granting goods,
confirmed completion, failed closure, not_confirmed pending behavior, cancelled
and declined handling, underpayment/manual-review handling, legacy transaction
lookup by foreign_id, and buyer redirect URL generation.

Use mocked MakePay SDK/API responses. Do not hit production APIs in tests.

Copy migration Markdown

The block below is a compact agent-ready brief for repository migrations. Copy it into Codex, Claude Code, Cursor, or another codebase-aware assistant when you want the model to perform the migration against a real project.

Agent-ready CoinsPaid migration Markdown

# Migrate CoinsPaid to MakePay

Use this as the working brief for an AI coding agent. Replace CryptoProcessing by CoinsPaid invoice creation, reusable deposit-address flows, exact-body HMAC-SHA512 signing, callback verification, transaction lookup, invoice/deposit status reconciliation, and provider 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

- CoinsPaid `X-Processing-Key` and `X-Processing-Signature` -> MakePay `X-MakeCrypto-Key-Id` and `X-MakeCrypto-Key-Secret` headers or SDK credentials.
- CoinsPaid HMAC-SHA512 over the exact JSON request body -> MakePay SDK request handling or credential headers.
- CoinsPaid `POST /api/v2/invoices/create` invoice creation -> MakePay `POST /api/partner/v1/makepay/payment-links` or the SDK create-payment-link helper.
- CoinsPaid invoice response `data.url` -> MakePay `paymentLink.publicUrl`.
- CoinsPaid invoice response `data.id` -> MakePay `paymentLink.uid`; keep the old invoice ID in a migration alias table while orders are in flight.
- CoinsPaid `foreign_id` -> MakePay `merchantOrderId`.
- CoinsPaid `end_user_reference` -> customer reference or internal metadata.
- CoinsPaid `title` and `description` -> MakePay `label` and `description`.
- CoinsPaid `currency`, `amount`, and optional `sender_currency` -> MakePay `payload.amount` and `payload.currency` or exact `payload.asset`.
- CoinsPaid `url_success` and `url_failed` -> MakePay success/failure redirect settings or hosted-page return handling.
- CoinsPaid `timer`, `fill_or_kill`, and `good_until_expired` -> MakePay payment-link expiry and underpayment/partial-payment business rules.
- CoinsPaid `POST /api/v2/addresses/take` reusable deposit address flow -> MakePay payment links for per-order checkout; keep address flow only for legacy deposits.
- CoinsPaid callback `X-Processing-Signature` -> MakePay `x-makepay-signature` HMAC verification over the raw request body.
- CoinsPaid callback root `id`, transaction `id`, and `txid` -> MakePay delivery ID plus `paymentLink.uid` idempotency.
- CoinsPaid `GET /api/v2/transactions/info` reconciliation -> MakePay payment-link lookup and webhook replay/reconciliation tooling.
- CoinsPaid statuses `created`, `processing`, `confirmed`, `failed`, `not_confirmed`, `cancelled`, `pending`, and `declined` -> MakePay `makepay.payment.status_changed` events and normalized order states.

## Agent prompt: inventory

You are migrating this repository from CryptoProcessing by CoinsPaid to MakePay. Search for CoinsPaid/CryptoProcessing API clients, `cryptoprocessing.com`, `app.cryptoprocessing.com`, `app.sandbox.cryptoprocessing.com`, `/api/v2`, `/invoices/create`, `/addresses/take`, `/transactions/info`, `X-Processing-Key`, `X-Processing-Signature`, HMAC-SHA512 signing helpers, `foreign_id`, `end_user_reference`, `sender_type`, `sender_data`, `url_success`, `url_failed`, `email_user`, `timer`, `fill_or_kill`, `good_until_expired`, `sender_currency`, invoice response `url`, callback handlers, callback root `id`, transaction IDs, `txid`, and status handling for `created`, `processing`, `confirmed`, `failed`, `not_confirmed`, `cancelled`, `pending`, and `declined`. Return a file-by-file migration plan with the exact functions that sign requests, create invoices, generate deposit addresses, store provider IDs, redirect buyers, verify callbacks, fetch transaction details, and reconcile order status. Do not edit files yet.

## Agent prompt: replace invoice creation

Implement MakePay payment-link creation in the existing CoinsPaid invoice creation path. Use the official MakePay SDK for this stack when available; otherwise call `POST /api/partner/v1/makepay/payment-links`. Remove `X-Processing-Key`/`X-Processing-Signature` request signing from the new-order path. Map `foreign_id` to `merchantOrderId`, `end_user_reference` and sender metadata to internal metadata, `title` to `label`, `description` to `description`, `amount` to `payload.amount`, and `currency` or `sender_currency` to `payload.currency` or `payload.asset`. Store `paymentLink.uid` and `paymentLink.publicUrl`, and keep nullable legacy CoinsPaid invoice ID and foreign_id fields for historical records.

## Agent prompt: replace deposit-address flows

Find any CoinsPaid `/addresses/take` flow that generates reusable customer deposit addresses. For one-off order checkout, replace it with MakePay payment links so each order has a `paymentLink.uid` and `paymentLink.publicUrl`. If the product still needs customer balance top-ups, keep the legacy address flow behind a provider flag until all old addresses and callbacks are reconciled, then design a MakePay-native top-up flow separately.

## Agent prompt: replace callback verification

Replace CoinsPaid callback verification with MakePay webhook verification. For legacy CoinsPaid invoices and deposit addresses, keep `X-Processing-Signature` verification by computing a lowercase hex HMAC-SHA512 over the exact raw request body with the CoinsPaid secret key and comparing it with a timing-safe compare. 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. For legacy callbacks, use callback root `id` plus transaction `id` or `txid` for idempotency.

## Agent prompt: normalize statuses

Map legacy CoinsPaid statuses explicitly during cutover. Invoice status `created` should not grant goods. Invoice status `processing` should remain pending until a `confirmed` callback arrives. Invoice status `confirmed` can complete the order. Invoice status `failed` should close the payment without marking it paid and preserve the `error` value for support. Deposit status `not_confirmed` should remain pending. Deposit status `confirmed` can complete balance credit or order fulfillment only after amount and currency match the order policy. Deposit status `cancelled`, transaction status `declined`, and known underpayment/minimum-amount/cross-currency exceptions should route to manual review, refund, or unpaid closure according to existing business rules.

## Agent prompt: dual-run cutover

Add a migration flag so newly created orders use MakePay while existing CoinsPaid invoices and deposit addresses can still receive callbacks until they are confirmed, failed, cancelled, declined, refunded, or expire through the current business rules. Route callbacks by provider, keep provider-specific IDs separate, and add logs that include provider, order ID, payment UID, delivery ID, legacy invoice ID, foreign_id, end_user_reference, callback ID, transaction ID, txid, and normalized status. Remove CoinsPaid API credentials, HMAC-SHA512 signing helpers, `X-Processing-Signature` callback verification, transaction-info polling, and deposit-address creation code only after there are no open legacy invoices, addresses, or pending callbacks.

## 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 CoinsPaid callback routing during cutover, CoinsPaid HMAC rejection, created and processing not granting goods, confirmed completion, failed closure, not_confirmed pending behavior, cancelled and declined handling, underpayment/manual-review handling, legacy transaction lookup by foreign_id, 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 CoinsPaid invoice `data.url`.
- New-order code no longer signs request bodies with `X-Processing-Signature`.
- 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 CoinsPaid callbacks keep HMAC-SHA512 verification until cutover is complete.
- Legacy created/processing/confirmed/failed/not_confirmed/cancelled/pending/declined paths are explicitly tested.
- Existing CoinsPaid invoices and deposit addresses remain reconcilable until the migration flag is fully removed.

Verification checklist

A new order creates exactly one MakePay payment link and stores paymentLink.uid.
The buyer redirect uses paymentLink.publicUrl instead of CoinsPaid invoice data.url.
New-order code no longer signs request bodies with X-Processing-Signature.
Webhook verification fails closed when x-makepay-signature is missing, stale, or invalid.
makepay.payment.status_changed handling is idempotent by delivery ID.
Completed orders cannot be regressed by delayed provider events.
Legacy CoinsPaid callbacks keep HMAC-SHA512 verification until cutover is complete.
Created, processing, confirmed, failed, not_confirmed, cancelled, pending, and declined legacy paths are explicitly tested.
Existing CoinsPaid invoices and deposit addresses still reconcile until the migration flag is removed.
Production logs include provider, order ID, payment UID, delivery ID, legacy invoice ID, foreign ID, end user reference, callback ID, transaction ID, txid, and normalized status.