PayIn Open is the independent open-source gateway for operators who want to deploy and manage their own payment infrastructure. It is separate from the current PayIn QR and Link product. Choosing Open means taking responsibility for the deployment, configuration, keys, monitoring and business integration; it is not a hidden hosted dashboard or an account upgrade.
Two products, different responsibilities
Current PayIn provides a USDC request that customers open from a QR or link, with a counter display and payment records. The hosted creation interface uses the current link API and returns application URLs. Merchants select their public receiving wallet and save private management access.
Open provides self-hosted building blocks. Its documentation covers order payments, address pools, long-lived deposit references, monitoring and callbacks. Those APIs belong to the operator's instance. Do not send historical Open order or deposit payloads to the current hosted link endpoint, and do not assume that a hosted management link is an Open API key.
What an operator manages
An Open deployment needs infrastructure and persistent state. Decide who owns the service, who can update it, where logs and backups are kept, and how a failed deployment is recovered. Verify the behavior of the actual version you run instead of treating a generic architecture diagram as proof of production readiness.
Address pools and wallet handling need their own procedures. Public addresses, derived addresses and private recovery information have different sensitivity. Keep recovery material out of application logs, screenshots, support messages and browser analytics. A self-hosted service does not eliminate the need to manage permissions and recovery.
Monitoring must follow the configured networks and confirmation rules. An observed transfer or notification needs to be matched to the intended order or deposit reference. Your business system still decides what a completed payment means for stock, service access, account credit or fulfillment.
Order and deposit references
An order workflow represents a particular requested payment. A deposit workflow associates a longer-lived receiving reference with a user or business account. They solve different accounting problems. A permanent reference is not a promise of automatic subscription charging, recurring wallet debits or a hosted customer balance supplied by the current PayIn product.
The imported Open documentation preserves detailed examples and operational guidance. Its broader network/token vocabulary describes configured self-hosted infrastructure. It should not be read as a feature list for hosted PayIn, which currently exposes USDC on Base, Polygon and Solana.
Begin with a controlled environment
Start by understanding the current repository, deployment requirements and sandbox examples. Exercise order creation, monitoring, payment queries, callbacks, retries and recovery using fixtures or a controlled test environment. Check duplicate and out-of-order notifications as well as the normal path. Do not use real customer data or real funds merely to test the website migration.
Before a production deployment, make backups and identify a rollback version. A code rollback does not undo a database schema change or reverse a transfer. Keep configuration and data migrations reviewable, and verify who can access logs and credentials.
Where the reference lives
This website now carries the complete imported English and Chinese Open documentation in the same visual system as PayIn's current guides. The introductions explain product scope; order/deposit examples remain full-length references. Old Cloud and Pro onboarding is retired and is not being revived as a hosted Open service.