PayPack · by Xiamen Shizhun Technology

Security model

The agent that spends money should not be the component that holds the keys. PayPack enforces that boundary: the agent gets a payment intent and a status, while merchant credentials, provider secrets and order records stay on the server side.

Trust boundary

Component	Has access to	Never has access to
AI agent / LLM	Amount, subject, channel, payment URL or QR payload, order status	Merchant private key, API v3 key, provider credentials
PayPack server-side component	Merchant keys, provider credentials, local order records	—

Because the agent only sees a payment intent, a compromised prompt cannot exfiltrate merchant credentials — there are none in the agent's context.

Callbacks are signals, not proofs

Provider callbacks are not signed by default in several fiat rails, which means anyone who learns the callback URL can send a POST. PayPack therefore never marks an order paid on the callback alone. Instead:

Token match — each order's callback URL carries a random token that must match a local order record.
Server-side query — PayPack asks the provider directly whether the order was actually paid.
Amount comparison — the amount reported by the provider must match the locally recorded order amount, so a small payment cannot unlock an expensive item.

Spend limits (safety fuse)

On-chain payments accept a spend_limit_daily value. When the limit is reached, further payments fail instead of silently draining the wallet. Limits are evaluated before the transaction is broadcast.

pay = AgentPay(
    wallet_config={"private_key": "0x..."},
    network="base-sepolia",
    spend_limit_daily=10.0,   # hard cap per 24h
)

Key management options

Signer	Key location	Use case
`LocalSigner`	Local key file / environment variable	Development, small deployments
`AWSKMSSigner`	Key never leaves AWS KMS	Production deployments

Swapping a local signer for KMS does not change the agent code — only the signer construction.

Auditable receipts

Every successful payment returns a receipt containing either an on-chain transaction hash or a provider order id. Receipts are the audit trail: they can be stored, re-verified and reconciled against the local order record.

What PayPack does not do

It does not hold user funds — settlement happens on the payment provider's rails or on-chain.
It does not authorize payments on the user's behalf — fiat payments require the user to confirm inside Alipay or WeChat.
It does not provide investment services or promise returns.

Operational recommendations

Start in sandbox (Alipay sandbox, Base Sepolia) before enabling production credentials.
Set a daily spend limit even when testing on-chain — it turns a bug into a failed call instead of a drained wallet.
Store every receipt; reconcile daily against your own order table.
Keep the callback endpoint behind HTTPS and treat repeated callbacks as normal (the state machine is idempotent).

Summary

The agent never holds merchant keys — only a payment intent and a status.
Callbacks are treated as signals; every payment is verified server-side and the amount is checked twice.
Daily spend limits act as a hard safety fuse for on-chain payments.
Local signer for development, AWS KMS for production, same agent code.
Every payment returns an auditable receipt (transaction hash or provider order id).

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