Earlier PayIn articles and documentation described a Cloud or Pro hosted gateway. Those names refer to historical product arrangements. This page preserves that context for people arriving from search, bookmarks or old integration material. It is not an invitation to register for, purchase or reactivate the former hosted service.
Identify the product behind your reference
An old guide may discuss organizations, API keys, address pools, order creation or long-lived deposit addresses. That vocabulary belongs to the earlier gateway and its self-hosted Open lineage. It is different from a public PayIn receiving link and its private management URL.
The current PayIn product provides USDC receiving requests through QR and Link workflows. It uses Base, Polygon and Solana and directs payments to a merchant-selected wallet. It does not provide an account balance that a merchant later withdraws from PayIn. The independent Open gateway remains available for operators who deploy their own system.
If you are starting a new receiving workflow
Prepare a wallet you control, select the receiving network explicitly, and create a public request with a recognizable business name. Use a counter QR for in-person sales or share a link through an existing channel. Save the private management access separately from the public request.
A request can have a fixed or customer-entered USDC amount. It does not automatically set up subscription collection, generate admission tickets, reserve inventory or map every payment to an individual invoice. Those business processes require your own workflow and, where appropriate, an integration.
Review the payment result before handing over goods or confirming access. A signed wallet message, a sound alert or a browser return to your success page is not sufficient evidence by itself. Fees and confirmation times can vary, and a refund remains a separate transfer arranged with the customer.
If you have a historical integration
Keep a copy of the documentation, request formats, configuration and records that describe the system you actually operated. Do not replace an API hostname or swap an old credential into the new API and assume compatibility. An old gateway order and a new payment link have different contracts and authorization boundaries.
The migrated Open reference preserves full order/deposit and webhook examples for self-hosted use. It labels their scope and uses an operator-instance placeholder where an old example could otherwise be mistaken for the current production API. Verify the reference against your actual version before changing an integration.
A website content migration is not a financial reconciliation or a data migration between products. It does not transfer balances, recover private credentials, reverse prior payments or establish that an old service is still operating. Retain your own payment records and follow the operational process for the instance you controlled.
If you want to operate the gateway
Use PayIn Open rather than looking for a hosted Pro signup. An operator manages deployment, storage, monitoring, address pools, backups and permissions. Begin in a controlled environment and test failure recovery as well as the normal payment path. Changing a website or code version does not reverse blockchain transactions.
Read the right guide
The new documentation index separates current hosted PayIn instructions from the complete Open reference. It also explains the difference between creation, customer approval, payment confirmation and fulfillment. The blog keeps historical articles with context notes so an older publication date or product name does not silently become a current feature promise.