Payment gateway API integration for custom websites

Prepare your website and credentials

Create the website entry in your merchant workspace and complete ownership verification using the instructions shown there. Configure the receiving accounts, plan and verification method for that website before testing payments.

Keep the website API key and webhook secret on your server. Do not put them in browser JavaScript, a public repository or a mobile client. Use the current developer guide in the PayNest workspace for the exact API base URL, authentication header, request fields and examples.

Create an invoice from your backend

Calculate the order amount from trusted server-side order data. Create the PayNest invoice using the documented endpoint and store the invoice identifier alongside your local order reference. Use the documented idempotency mechanism when retrying creation so a repeated request does not create unintended extra invoices.

Redirect the customer to the checkout URL returned by PayNest. Do not build a guessed checkout URL or trust a total submitted directly by the browser without validating it against the order.

Handle the customer’s return

A return URL helps the customer get back to your website after checkout. It is a navigation mechanism, not payment evidence. Your return page can show the latest status retrieved by your backend while waiting for verification.

Only mark an order paid after a trusted payment confirmation. Keep pending, cancelled and expired outcomes distinct from a paid invoice, using the exact statuses documented for the deployed API version.

Verify signed webhooks

PayNest sends signed payment updates, including the invoice.paid event. Follow the current developer guide for the exact headers, timestamp rules and signature calculation. Verify the original request body before using the event to change an order.

Match the confirmed invoice to the expected website, local order and amount. Process each event idempotently so duplicate deliveries do not trigger duplicate fulfillment. Store enough information to investigate delivery issues, while keeping credentials and sensitive payment data out of public logs.

Test retries, cancellation and delayed updates

• Retry the same invoice-creation operation using the documented idempotency behavior.
• Verify that a valid paid event updates the intended order once.
• Reject invalid signatures and stale events according to the documented rules.
• Check that duplicate webhook deliveries do not duplicate fulfillment.
• Verify cancelled and expired outcomes without treating them as paid.
• Use the documented status endpoint to investigate delayed notifications and reconcile an order.

Use the current developer guide

The workspace’s integration guide contains the API contract and implementation examples. Use it for exact request and response fields, cancellation behavior and webhook verification; this page intentionally explains the workflow without inventing endpoint names or signature formats.

For WordPress with WooCommerce, start with the PayNest plugin guide instead. For a custom backend, keep payment confirmation on the server and test the complete order lifecycle before launch.

Related payment guides