Redirects and Callbacks

🧾 Receipt Page Settings

Once a payment is completed, you need to return the customer to your website. E-xact offers several return methods configurable in the Receipt Page Settings tab of your dashboard.

Payload Differences

Depending on the return method you select below, the data payload sent back to your server will change. Some methods return our "Full" payload (Authorize.net + E-xact fields), while others return a "Short" payload (Authorize.net fields only).

Please review our Response Codes & Approvals guide to ensure you are listening for the correct approval variables based on your chosen method.

User-Initiated Navigation (Requires a customer click)

These methods add a link or button to the standard transaction receipt that is displayed to the customer. Actions are triggered only if the customer clicks the link or button.

• LINK: Displays a basic HTML link back to your site. No transaction data is sent.
• GET: Displays a "Return to Merchant" button. Clicks send transaction results via URL query parameters. (Returns the Short Payload: Auth.net fields only)
• POST: Displays a button. Clicks send transaction results via hidden HTTP POST data. (Returns the Short Payload: Auth.net fields only)

Automatic Navigation (No click required)

These methods do not display the standard transaction receipt to the customer. Instead, the customer's browser automatically submits an HTTP form to the configured Receipt Link. It is up to the merchant's server hosting the Receipt Link website to generate and display the transaction receipt to the customer.

• AUTO-GET: Sends the transaction results as HTTP GET parameters. Instantly redirects the user via URL query parameters. (Returns the Short Payload: Auth.net fields only)
• AUTO-POST: Sends the transaction results as HTTP POST parameters. Instantly redirects the user via an HTTP POST. (Returns the Full Payload: Auth.net + E-xact proprietary fields)

🔄 Relay Response vs. Silent Post

These two features generate the most questions. Both are server-to-server callbacks used to update your database when a transaction completes, but they serve entirely different purposes.

📘

Certain combinations of receipt page settings can increase the reliability and redundancy of the receipt page data transmission. Merchants can use both a browser-to-server (AUTO-POST, AUTO-GET) and server-to-server connection (Silent Post), to provide additional redundancy.

1. Relay Response (Advanced Routing)

Relay Response allows your server to dictate the HTML of the final receipt page the customer sees.

How it works:

1. Transaction finishes. E-xact temporarily pauses the customer's browser.
2. E-xact makes a background HTTP POST to your designated Relay Response URL with the transaction results.
3. Your server processes the data, saves it to your database, and replies to E-xact with standard HTML.
4. E-xact displays your HTML directly to the customer's browser.

🔒

Security Note: We encourage merchants to validate the incoming data to ensure it came from E-xact. E-xact sends an x_MD5_Hash in the payload. You can reconstruct this hash on your server to verify the signature.

2. Silent Post (Background Sync)

Silent Post is strictly for background database syncing and does not affect the customer's visual flow. (Returns the Full Payload: Auth.net + E-xact proprietary fields)

How it works:

1. Transaction finishes.
2. E-xact sends an HTTP POST to your Silent Post URL containing the full transaction results.
3. E-xact ignores your server's response and immediately redirects the customer to your standard receipt page (based on your Receipt Page Settings).

Which should I use?

• Use Silent Post if you just need to reliably update your database or inventory in the background, but want E-xact to handle the heavy lifting of the receipt page redirects.
• Use Relay Response only if your application absolutely must control the final HTML receipt rendered to the user.

Allowlisting Outbound Callbacks

Many enterprise firewalls and cloud providers (like AWS or Cloudflare) will block incoming HTTP POST requests by default.

To ensure uninterrupted delivery of transaction receipts and webhooks, please allowlist the following outbound IP addresses on your firewall:

• 52.10.249.55
• 52.7.145.140

📘

Note on Security

We highly recommend configuring your receiving endpoint to only accept traffic from the IPs listed above. This prevents malicious third parties from spoofing callback payloads to your server.