Callback URL is an address a merchant registers with a payment provider or authorization server so the provider knows where to send the customer, or a status message, once a step finishes. It does two jobs: returning the shopper's browser after an off-site step such as a bank challenge, and receiving a server-to-server notice, often called a webhook, with the final status. The browser redirect is weak evidence, so orders should be fulfilled on the signed notification or a direct status query. In OAuth 2.0 the redirect URI must be pre-registered and matched exactly. Endpoints accept HTTPS only, verify HMAC-SHA256 signatures and process idempotently, because providers resend unacknowledged notifications.
What is a callback URL in a payment API
In a typical callback url in payment api setup, the merchant passes the address inside the payment request (as `return_url`, `redirect_url` or `notification_url`) or sets it once in the provider's dashboard. A checkout might send a €89.00 payment with `return_url=https://shop.example/order/5521/complete`. After a bank challenge or wallet approval, the provider redirects the browser to that address with the payment ID appended.
The server-to-server variant is what most providers call a webhook: an HTTP POST from the provider's servers to the merchant's endpoint carrying the final status, sent whether or not the shopper's browser ever returns.
How does callback URL work
The merchant creates the payment with its URLs, and the customer is sent to a hosted payment page, a bank or a wallet. Once authorization completes, the browser is redirected to the return URL while the provider separately posts a notification to the merchant's server.
The redirect is weak evidence of payment: a shopper can close the tab, lose signal, or edit the query string by hand. Well-built integrations use the redirect only to show a "thank you" or "payment failed" page, and fulfil orders on the signed server notification or on a direct status query to the API.
Callback URLs in OAuth and open banking
In OAuth 2.0 the same concept is called a redirect URI: the authorization server sends the one-time authorization code there after the user consents. It must be pre-registered and matched exactly, because a loose wildcard match lets an attacker steer the code to a domain they control. In open banking, an AISP or PISP registers redirect URIs with each bank; after the customer passes strong authentication in the banking app, they land back at the provider's page carrying the code.
Securing a payment callback endpoint
The endpoint accepts HTTPS only. Every notification is authenticated by checking an HMAC-SHA256 signature computed with a secret shared with the provider, or by re-fetching the status from the API instead of trusting the payload. Processing is idempotent: providers resend notifications when they do not receive a 2xx response within a few seconds, sometimes for days, so the handler keys on the transaction ID, much like an idempotency key, ignores duplicates and answers fast, queuing heavy work for later.
Callback URL vs return URL naming
Providers disagree on vocabulary: one calls the browser redirect a "callback", another reserves the word for the server notification. Checking which of the two a field controls, and whether it is signed, prevents the most common integration error: shipping goods because a browser landed on a success page.