This page describes the current hosted PayIn creation interface. It is separate from PayIn Open's self-hosted order/deposit APIs. Do not send an Open order request to this endpoint or assume that an old Cloud API key grants access to the new service.
Create a receiving request
The website uses POST https://api.payin.com/api/v1/link/create with a JSON request. A minimal example is:
{
"name": "Your Business",
"theme": "light",
"evmAddress": "0x1111111111111111111111111111111111111111",
"allowedNetworks": ["base"]
}
The address above is an illustrative public placeholder. Replace it with a verified address you control before using the service; do not send funds to the example. This documentation does not submit a request.
For Polygon select "polygon". For Solana select "solana" and supply solanaAddress instead of evmAddress. The website asks for one network explicitly. An address-format check does not establish wallet ownership, and an EVM address does not identify its network.
Optional fixedAmount is a decimal USDC string. Omit it for a customer-entered amount. Use six or fewer decimal places and the website's accepted range0.01–1,000,000. Do not use floating-point multiplication to compare token atomic units in your own integration.
Use returned URLs
A successful response includes linkId, payUrl, posUrl and adminUrl, together with management authorization data. Use the returned URLs; do not construct management URLs or infer credentials from a public link identifier. In production these application URLs use https://app.payin.com.
payUrl: the customer-facing request to share or encode in the QR.posUrl: the counter display for your receiving workflow.adminUrl: private management access that must be saved securely.
Do not log an entire creation response to shared logs or analytics. Do not expose management credentials in page titles, public links, screenshots or a customer-facing QR. Creating another request is not a recovery mechanism for a lost credential.
Optional integration settings
callbackUrl and callbackSecret configure a payment notification destination and signing secret. The website requires a signing secret when notifications are enabled. redirectUrl is a return destination for the customer. A browser return, including one to your own success page, is not payment evidence.
The current link-creation form does not expose a metadata field. For individual order matching, use an integration that carries and verifies a specific business identifier through the supported checkout flow. A shared link and a preset amount cannot by themselves identify an order or prevent two customers choosing the same amount.
Treat failures carefully
Validate name, network, receiving address and amount before submitting. The website prevents duplicate clicks while a creation request is pending and uses a timeout. A timeout means the browser did not receive a complete answer; it is not proof that a remote operation did not happen. Treat payment-submission timeouts even more carefully: query the persisted result and reconcile before asking for another signature.
The public capabilities endpoint is GET https://api.payin.com/api/v1/capabilities. It reports advertised networks and configuration; it is not a live payment or balance test. Production release checks confirmed the link-creation contract using a synthetic request that was subsequently disabled. They did not move funds or establish end-to-end wallet settlement for every supported wallet.
Confirm before fulfillment
Use a verified server-side payment record as the basis for fulfillment. Check the requested amount, currency, network, business reference and status. Keep your own idempotency key for a fulfillment action, so that a retried notification cannot ship an item or admit a guest twice. See payment notifications for the operational boundary.