AI 迁移

B2BINPAY migration

Use an AI agent to replace B2BINPAY deposits, OAuth tokens, callback HMACs, and deposit/transfer status handling with MakePay APIs and SDKs.

Overview

This AI compatibility guide gives a senior developer or coding agent a direct path for replacing B2BINPAY with MakePay. It covers deposit creation, buyer payment pages, deposit IDs, OAuth token authentication, callback HMAC verification, deposit and transfer statuses, and SDK installation.

Use it when the existing codebase calls the B2BINPAY v3 API directly, wraps it behind a payment provider abstraction, or stores B2BINPAY deposit IDs and tracking IDs on orders. B2BINPAY documents current v3 behavior in API overview, Authentication, Deposit methods, and Transfer methods.

Migration map

B2BINPAY integrations usually obtain an OAuth bearer token with POST [base]/token/, create a deposit with POST [base]/deposit/, redirect the buyer to payment_page, and verify callback meta.sign using a callback secret and HMAC-SHA256. In MakePay, use payment links, signed webhooks, and SDK helpers for the same order flow.

B2BINPAY surfaceMakePay replacement
POST [base]/token/ OAuth token requestX-MakeCrypto-Key-Id and X-MakeCrypto-Key-Secret headers or SDK credentials
Content-Type: application/vnd.api+json JSON:API envelopesNative MakePay SDK objects or direct JSON request bodies
POST [base]/deposit/ deposit creationPOST /api/partner/v1/makepay/payment-links or SDK create-payment-link helper
Response payment_pagepaymentLink.publicUrl
Deposit idpaymentLink.uid; keep a legacy alias during cutover
tracking_idmerchantOrderId
labellabel or description
target_amount_requested and source_amount_requestedpayload.amount plus payload.currency or exact payload.asset
Wallet relationship and currency.data.idDestination asset selection when the merchant must force asset or chain
callback_urlMakePay webhook endpoint configured in MakeCrypto
payment_page_redirect_url and button textMakePay success/failure redirects or hosted-page return handling
confirmations_neededMakePay confirmation/state policy plus order-status gating
inaccuracy and unresolved depositsUnderpayment, overpayment, or manual-review business rules
meta.sign, meta.time, and callback_secretx-makepay-signature HMAC verification over the raw request body
Deposit and transfer numeric statusesmakepay.payment.status_changed webhooks and normalized order states

For a clean migration, keep provider-specific IDs separate. Existing B2BINPAY deposits should continue to reconcile until they are paid, canceled, unresolved, blocked, failed, or otherwise closed by the 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 B2BINPAY usage

You are migrating this repository from B2BINPAY to MakePay. Search for B2BINPAY
API clients, b2binpay domains, v3.api.b2binpay.com,
v3.api-sandbox.b2binpay.com, /token/, /deposit/, /transfer/, OAuth bearer token
handling, application/vnd.api+json JSON:API envelopes, payment_page,
tracking_id, label, callback_url, callback_secret, meta.sign, meta.time,
HMAC-SHA256 callback verification, deposit status handling for 2, 3, 4, and 5,
and transfer status handling for -3, -2, -1, 0, 1, and 2.

Return a file-by-file migration plan with the exact functions that obtain
tokens, create deposits, store provider IDs, redirect buyers, verify callbacks,
read transfer data, and reconcile order status. Do not edit files yet.

Replace deposit creation

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

Remove the B2BINPAY token fetch from the new-order path. Map tracking_id to
merchantOrderId, label to label or description, target_amount_requested or the
merchant order amount to payload.amount, and wallet/currency selection to
payload.currency or payload.asset. Store paymentLink.uid and
paymentLink.publicUrl, and keep nullable legacy B2BINPAY deposit ID fields for
historical records.

Replace callback verification

Replace B2BINPAY callback verification with MakePay webhook verification. For
legacy B2BINPAY deposits, keep callback_secret HMAC-SHA256 verification until
open deposits are closed. If the callback includes a transfer, keep the legacy
message format transfer.status + transfer.amount + deposit.tracking_id +
meta.time. If it does not include a transfer, keep the legacy message format
deposit.status + optional deposit.tracking_id + meta.time.

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.

Normalize statuses

Map legacy B2BINPAY statuses explicitly during cutover. Deposit status 2
(Created) should not grant goods. Deposit status 3 (Paid) can complete the
order. Deposit status 4 (Canceled) should close the legacy payment without
marking the order paid. Deposit status 5 (Unresolved) should route to
underpayment, overpayment, late-payment, or manual-review handling.

For transfer statuses, -3 (Canceled), -2 (Blocked), and -1 (Failed) should not
grant goods. 0 (Created) and 1 (Unconfirmed) should remain pending. 2
(Confirmed) can support completion only when it matches the deposit/order amount
and risk policy.

Dual-run cutover

Add a migration flag so newly created orders use MakePay while existing
B2BINPAY deposits can still receive callbacks until they are paid, canceled,
unresolved, blocked, failed, 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 deposit ID,
tracking_id, transfer ID, txid, and normalized status.

Remove B2BINPAY API credentials, token refresh code, JSON:API envelope builders,
callback_secret, and callback verifier code only after there are no open legacy
deposits.

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 B2BINPAY callback routing during
cutover, B2BINPAY HMAC rejection, deposit status 2 not granting goods, deposit
status 3 completing orders, deposit status 4 closing orders unpaid, deposit
status 5 manual review, transfer statuses -3/-2/-1/0/1/2, 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 B2BINPAY migration Markdown
# Migrate B2BINPAY to MakePay

Use this as the working brief for an AI coding agent. Replace B2BINPAY deposit creation, OAuth token authentication, JSON:API request envelopes, callback HMAC verification, deposit/transfer 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

- B2BINPAY `POST [base]/token/` OAuth token request -> MakePay `X-MakeCrypto-Key-Id` and `X-MakeCrypto-Key-Secret` headers or SDK credentials.
- B2BINPAY `Content-Type: application/vnd.api+json` JSON:API envelopes -> native MakePay SDK objects or direct JSON request bodies.
- B2BINPAY `POST [base]/deposit/` deposit creation -> MakePay `POST /api/partner/v1/makepay/payment-links` or the SDK create-payment-link helper.
- B2BINPAY response `payment_page` -> MakePay `paymentLink.publicUrl`.
- B2BINPAY deposit `id` -> MakePay `paymentLink.uid`; keep the old deposit ID in a migration alias table while orders are in flight.
- B2BINPAY `tracking_id` -> MakePay `merchantOrderId`.
- B2BINPAY `label` -> MakePay `label` or `description`.
- B2BINPAY `target_amount_requested` and `source_amount_requested` -> MakePay `payload.amount` and `payload.currency` or exact `payload.asset`.
- B2BINPAY wallet relationship and `currency.data.id` -> MakePay destination asset selection when the merchant must force asset or chain.
- B2BINPAY `callback_url` -> MakePay webhook endpoint configured in MakeCrypto.
- B2BINPAY `payment_page_redirect_url` and button text -> MakePay success/failure redirect settings or hosted-page return handling.
- B2BINPAY `confirmations_needed` -> MakePay confirmation/state policy plus order-status gating.
- B2BINPAY `inaccuracy` and unresolved deposits -> underpayment, overpayment, or manual-review business rules.
- B2BINPAY callback `meta.sign`, `meta.time`, and `callback_secret` HMAC-SHA256 verification -> MakePay `x-makepay-signature` HMAC verification over the raw request body.
- B2BINPAY deposit statuses `2`, `3`, `4`, and `5` plus transfer statuses `-3`, `-2`, `-1`, `0`, `1`, and `2` -> MakePay `makepay.payment.status_changed` events and normalized order states.

## Agent prompt: inventory

You are migrating this repository from B2BINPAY to MakePay. Search for B2BINPAY API clients, `b2binpay`, `v3.api.b2binpay.com`, `v3.api-sandbox.b2binpay.com`, `/token/`, `/deposit/`, `/transfer/`, OAuth bearer token handling, `application/vnd.api+json` JSON:API envelopes, `payment_page`, `tracking_id`, `label`, `callback_url`, `callback_secret`, `meta.sign`, `meta.time`, HMAC-SHA256 callback verification, deposit status handling for `2`, `3`, `4`, and `5`, and transfer status handling for `-3`, `-2`, `-1`, `0`, `1`, and `2`. Return a file-by-file migration plan with the exact functions that obtain tokens, create deposits, store provider IDs, redirect buyers, verify callbacks, read transfer data, and reconcile order status. Do not edit files yet.

## Agent prompt: replace deposit creation

Implement MakePay payment-link creation in the existing B2BINPAY deposit creation path. Use the official MakePay SDK for this stack when available; otherwise call `POST /api/partner/v1/makepay/payment-links`. Remove the B2BINPAY token fetch from the new-order path. Map `tracking_id` to `merchantOrderId`, `label` to `label` or `description`, `target_amount_requested` or the merchant order amount to `payload.amount`, and wallet/currency selection to `payload.currency` or `payload.asset`. Store `paymentLink.uid` and `paymentLink.publicUrl`, and keep nullable legacy B2BINPAY deposit ID fields for historical records.

## Agent prompt: replace callback verification

Replace B2BINPAY callback verification with MakePay webhook verification. For legacy B2BINPAY deposits, keep `callback_secret` HMAC-SHA256 verification until open deposits are closed. If the callback includes a transfer, keep the legacy message format `transfer.status + transfer.amount + deposit.tracking_id + meta.time`. If it does not include a transfer, keep the legacy message format `deposit.status + optional deposit.tracking_id + meta.time`. 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 B2BINPAY statuses explicitly during cutover. Deposit status `2` (Created) should not grant goods. Deposit status `3` (Paid) can complete the order. Deposit status `4` (Canceled) should close the legacy payment without marking the order paid. Deposit status `5` (Unresolved) should route to underpayment, overpayment, late-payment, or manual-review handling. Transfer statuses `-3` (Canceled), `-2` (Blocked), and `-1` (Failed) should not grant goods. Transfer statuses `0` (Created) and `1` (Unconfirmed) should remain pending. Transfer status `2` (Confirmed) can support completion only when it matches the deposit/order amount and risk policy.

## Agent prompt: dual-run cutover

Add a migration flag so newly created orders use MakePay while existing B2BINPAY deposits can still receive callbacks until they are paid, canceled, unresolved, blocked, failed, 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 deposit ID, tracking ID, transfer ID, txid, and normalized status. Remove B2BINPAY API credentials, token refresh code, JSON:API envelope builders, callback_secret, and callback verifier code only after there are no open legacy deposits.

## 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 B2BINPAY callback routing during cutover, B2BINPAY HMAC rejection, deposit status 2 not granting goods, deposit status 3 completing orders, deposit status 4 closing orders unpaid, deposit status 5 manual review, transfer statuses -3/-2/-1/0/1/2, 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 B2BINPAY `payment_page`.
- New-order code no longer fetches a B2BINPAY OAuth token.
- 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 B2BINPAY callbacks keep `callback_secret` HMAC verification until cutover is complete.
- Legacy created/paid/canceled/unresolved/blocked/failed/unconfirmed/confirmed paths are explicitly tested.
- Existing B2BINPAY deposits 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 B2BINPAY payment_page.
  • New-order code no longer fetches a B2BINPAY OAuth token.
  • 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 B2BINPAY callbacks keep callback_secret HMAC verification until cutover is complete.
  • Created, paid, canceled, unresolved, blocked, failed, unconfirmed, and confirmed legacy paths are explicitly tested.
  • Existing B2BINPAY deposits still reconcile until the migration flag is removed.
  • Production logs include provider, order ID, payment UID, delivery ID, legacy deposit ID, tracking ID, transfer ID, txid, and normalized status.

需要合作伙伴设置帮助?

在 MakeCrypto 中打开支付链接详情,复制真实支付 UID 的生成代码片段;也可以返回门户管理商户设置。

打开门户