PayPack · by Xiamen Shizhun Technology

How an AI agent completes a payment with PayPack

PayPack lets an AI agent create a payment intent, receive a payment link or QR payload, and get the final payment state back — without ever touching merchant keys or card data. This page walks through the six steps of one payment.

Overview

There are two sides to every payment: the agent side (wants to pay) and the merchant side (holds the keys and the money). PayPack sits between them and keeps the boundary explicit.

Side	Knows	Never knows
Agent	Amount, subject, channel, order status	Merchant keys, provider secrets, user identity
Merchant server	Keys, provider credentials, order records	—

The six steps

Step 1 — The agent creates a payment intent. The agent calls PayPack with three values: the amount (in CNY), a subject line, and a channel (alipay or wechat). PayPack validates the request and creates a local order record with status pending.

Step 2 — PayPack creates the provider order. The server-side component calls the payment provider with the merchant credentials and receives a payment URL or QR payload. The callback URL is decided by the server, never by the caller.

Step 3 — The agent receives the payment target. PayPack returns an order id, a payment URL, and the current status. The agent can show the URL to the user or render the QR code — it does not need to understand the payment protocol.

Step 4 — The user pays in their own app. The user completes the payment inside Alipay or WeChat Pay. PayPack is not involved in the user's authorization flow.

Step 5 — PayPack receives a callback, and treats it as a signal only. Provider callbacks are not signed, so a callback alone never changes an order to paid. PayPack instead queries the provider directly to confirm the order server-side, and compares the reported amount against the local order record.

Step 6 — The agent receives the final state. After verification, the order moves from pending to paid (or stays pending / becomes failed). The agent polls or is notified, then continues its task.

Why callbacks are not trusted

An unsigned callback can be sent by anyone who knows the endpoint. If a callback were enough to mark an order paid, anyone could upgrade a plan for free. PayPack therefore uses a three-part check:

Callback token — each order's callback URL carries a random token that must match a local order.
Server-side query — the provider is asked directly whether the order was actually paid.
Amount comparison — the paid amount must match the local order amount, so a ¥1 payment cannot buy a higher plan.

State machine

Status	Meaning	Next
`pending`	Order created, payment not confirmed	paid / failed
`paid`	Verified server-side, amount matched	terminal
`failed`	Provider reports failure or amount mismatch	terminal

Transitions are idempotent: a repeated callback cannot move an order from paid to paid twice, or create a second entitlement.

What the agent sees

{
  "order_id": "pp_8f3c1a7e",
  "pay_url": "https://provider.example/pay/...",
  "status": "pending",
  "amount": "9.90",
  "currency": "CNY",
  "channel": "alipay"
}

After verification the same record reports "status": "paid" with a paid_at timestamp.

Summary

An agent payment is six steps: intent → provider order → payment target → user pays → callback as signal → server-side verification.
The agent never sees merchant keys or provider secrets.
Callbacks are never trusted on their own; every payment is verified against the provider.
The order amount is checked twice, so partial payments cannot unlock higher plans.
The order state machine is idempotent — repeated callbacks cannot double-apply.

PayPack is a developer tool for payment integration. It does not provide investment services, does not promise returns, and does not hold user funds.
Operated by Xiamen Shizhun Technology Co., Ltd. (Unified Social Credit Code: 91350211MA34XHGG5T) · Website: rhcjw.com · ICP filing: 闽ICP备2024041817号-2