The payment form will automatically validate the input provided by the customer and provide the customer the opportunity to change it before submitting the payment for processing. In the event of a payment decline or error, the customer remains on the form with the opportunity to revise their input and try again.
If the transaction processing is successful, the customer is presented with an optional receipt page, and a Continue button which returns control to the merchant’s site. Additionally, the customer may optionally be presented with a Cancel button to return to the merchant’s site before the transaction is processed.
If the customer returns to the merchant’s site, the information passed to the merchant depends on the method used to integrate the form.
However, it is beneficial to provide some small amount of information indirectly through a third page. You can embed our hosted form in an IFrame, which enables us to embed your IFrameCommunicator page inside our hosted form. This channel of communication allows us to send messages to your IFrameCommunicator page. As long as your communicator page is hosted on the same domain as your main page, it can communicate with your main page.
This channel of communication is used to pass a few basic messages to a listener script running on your page that calls the form:
- Ideal height and width of the window - enables you to resize the frame and avoid any scrollbars from appearing.
- Request Succeeded - returned when the transaction is completed at Authorize.Net. Transaction response parameters (such as transaction ID) are returned.
- Request Cancelled - returned when the merchant cancels the hosted form.
Note: If you plan to use IFrame, you must send the hostedPaymentIFrameCommunicatorUrl parameter in the getHostedPaymentPageRequest method.
Note: You must use HTTPS when using IFrameCommunicator.
When not using an IFrame, the continue/return URL and cancel URL create buttons that when clicked cause the browser to perform a simple GET request to that URL. No other information about the transaction is provided directly. When using the redirect method, an Authorize.Net generated receipt will be shown and cannot be disabled.
With any of the form integration methods, information specific to the customer can be passed back to the merchant’s server by embedding it in the continue/return URL or the cancel URL. By embedding information into the URL that is provided in the token request, the merchant server can identify the specific customer and transaction that has been processed when the customer returns. Any name-value pairs embedded in the URL should be URL-encoded to ensure correct processing in the form request.
Additionally, developers can register for Webhooks to receive real-time notifications when transactions are either declined or approved. Using Webhooks notifications, a developer would still be notified if a transaction was processed but the customer closed the browser before following the return URL.
Because this is a hosted payment form, processor card declines and other errors are handled within the form itself. For example, the image below shows a general processor decline (response code 2), simulated by passing the zip code 46282 in the Sandbox environment (see Sandbox Testing Guide for more details on simulating errors). The consumer can try another card or change field details.
For AFDS Declines (for example when there is a billing address mismatch – using the test zip 46205), the form itself will handle the error notification and the consumer will be able to update their information and try again.