The payment form will automatically validate the input provided by the customer and give 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 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.
This channel of communication is used to pass a few basic messages back to a listener script running on your main page (the 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. You can use this notification to know when to look for those changes through the Transaction Reporting API. Transaction response parameters (such as transaction ID) are returned with this notification.
- Request Cancelled - returned when the customer cancels the hosted form.
Note: If you host our form in an IFrame, you must include the address to your IFrameCommunicator page in the
hostedPaymentIFrameCommunicatorUrl parameter in the
getHostedPaymentPageRequest method. To ensure you receive a response code, you must also set
Note: You must use HTTPS in the URL to your IFrameCommunicator page.
For an example of an IFrameCommunicator page and more information about the messages passed, see our sample IFrameCommunicator.html in our sample application on GitHub.
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. The consumer can try another card or change field details. See the Sandbox Testing Guide for more details on simulating errors.
For declines caused by Advanced Fraud Detection Suite filters -- for example, when there is a billing address mismatch, using the test ZIP Code 46205 -- the form itself will handle the error notification and the consumer will be able to update their information and try again.