PayPack · by Xiamen Shizhun Technology
PayPack vs. building your own agent payment layer
You can integrate Alipay and WeChat Pay yourself. The question is what that costs over the life of the product — not just at the first commit.
What each option actually contains
| Concern | Build your own | With PayPack |
|---|
| Provider signing (RSA2 / API v3) | Implement and keep correct across provider changes | Handled by the signer |
| Payment intent model | Design your own | pay.send(...) with a fixed shape |
| Callback handling | Verify, deduplicate, reconcile | Signal-only by design, verified server-side |
| Order state machine | Design and test idempotency yourself | Built in (pending / paid / failed) |
| Spend limits | Build your own guard rails | spend_limit_daily |
| Multi-rail routing | Separate code path per provider | One call, explicit rail |
| Agent tool integration | Wrap everything into a tool yourself | PayPackTool for LangChain, Dify plugin |
| Merchant onboarding | You still do it | You still do it |
| Provider approval | You still do it | You still do it |
What you still need either way
- A merchant account for Alipay and/or WeChat Pay (approval is the long pole, not the code).
- Compliance with the provider's rules — the middleware does not grant you merchant status.
- Your own order records — PayPack keeps a local order, but your product still owns its entitlement model.
- Operational monitoring — you should alert on failed payments regardless of the library used.
Where building your own wins
- You need a payment flow the library does not model (exotic split settlement, custom refund policy).
- You must keep zero third-party dependencies in the payment path.
- You already have a mature in-house payment platform.
Where PayPack wins
- You want the agent to be able to pay today, not after a payment subsystem project.
- You need both fiat and on-chain rails behind one call.
- You want callback safety and idempotency handled once, not per provider.
- You are shipping a LangChain or Dify agent and want a native tool.
A pragmatic decision rule
- Is a human in China paying? → you need Alipay or WeChat Pay; the merchant approval time dominates either way.
- Is another machine paying? → x402 removes the merchant-account step entirely.
- Are both true? → start with the rail you can get approved fastest, and keep the other behind the same
pay.send call.
Summary
- Building your own means owning signing, callbacks, idempotency, limits and multi-rail routing.
- PayPack packages those into one payment call, plus native LangChain and Dify integration.
- Merchant onboarding and provider approval are required either way.
- Build your own if you need a flow PayPack does not model; otherwise the middleware removes a subsystem project.
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