Payment flow process (Merchant API)
The diagram below shows a typical payment flow using the Merchant API. The actual flow depends on the payment method, for example credit card payments, or invoice payments. For detailed information about the different payment methods, see Payment methods and providers.
You set up the callback pages and send them as parameters in the payment flow, or set them up under Home > Terminal Settings in the Merchant Information Interface.
Javascript and other active content is stripped from the callback pages. To limit the design work needed, all HTTP (not HTTPS) resources (images, CSS, etc) are proxied. Any links/forms are rewritten so that the page works as if it was served directly to the customer.
Javascript and other active content is stripped from the callback pages. To limit the design work needed, all HTTP (not HTTPS) resources (images, CSS, etc) are proxied. Any links/forms are rewritten so that the page works as if it was served directly to the customer.
For more information about specific scenarios, like subscriptions, or gift card payments, see Integration scenarios (Merchant API).
- Your customer finishes shopping and clicks Check Out, you (the merchant) collect data you need to complete the order, such as name, e-mail, shipping address, and so on.
- Your customer is now on the second last page of the checkout, which contains a button labelled "Pay", "Continue to secure payment" or something similar. When the customer clicks Pay, you send us the information about the payment you want us to facilitate, using the createPaymentRequest API method.
- In response, the createPaymentRequest method provides you with a URL to which you redirect your customer in order to complete the payment. You can redirect your customer using server side redirect, Meta-refresh, or JavaScript.
- The customer accesses the payment page via our secure payment gateway. To ensure that this page is secure, we deliver it using SSL.
- Depending on the type of payment (credit card, invoice, paypal, etc.), the customer supplies the final payment information. AltaPay will then contact the underlying service of the payment method to validate this information. Most of these can respond back right away with a success/decline, for the more complex types of payment, please refer to Payment Flow by Payment Type.
- On receipt of the response, we send the results to you via a callback (okay/fail). When your customer has completed the payment via our secure payment gateway, a callback response is sent to the relevant callback page:
- If the payment succeeds, the callback data is sent to the OK page (callback_ok), and your customer is redirected to the same page.
- If the payment fails, the callback data is sent to the fail page (callback_fail), and your customer is redirected to the same page.
- If the payment cannot be finalized right away, the first set of callback data is sent to the open page (callback_open), and your customer is redirected to the same page. When the payment is later finalized, another set of callback data, containing the result of the payment, is sent to the notification page (callback_notification). At this point, your customer has left the payment process, and you will need to use another mean of notification, such as e-mail.
- You must then register the payment information for further processing. If the payment is successful you must either provide a receipt page, or respond with a server-side redirect (HTTP 30X). AltaPay will then serve the page you delivered, or in case of a redirect proxy that directly to the customer.
We will time out after 7 seconds if we cannot retrieve the hostname of your callback page or if we cannot create a network connection. If we create a network connection we will time out if we do not get a response from you within 28 seconds. The customer is shown an error message with the order number and the payment ID.
When integrating using the Processor API instead of the Merchant API, no callback pages are used, but the responses are delivered directly to you. For more information, see Processor API.