1. The Return Flow

After a successful (or failed) deposit, the customer is shown a transaction summary page in the Hosted Payment Page. At the bottom of the page, a “Continue” button appears. When clicked, the customer is redirected to the return_url you specified during the initialization of the payment.

📘

HTTP GET vs POST Methods

By default, the return URL is accessed using the HTTP POST method. If your callback expects a GET request, you must include at least one query string parameter in your Return URL. If no parameters are natively needed, you must include a dummy parameter (e.g., ?get=1).

Handling Multiple Attempts

In some cases, the customer may be offered additional actions after a transaction completes:

• "Try Again" button after a declined transaction.
• "Make Another Payment" option after a successful deposit.

These options allow the customer to retry within the exact same Cashier session, which introduces the risk of reusing the exact same order_id.

⚠️

Preventing Duplicate Orders

To mitigate the risk of order_id reuse, you should either implement strict Validation on your backend or enable the Back Office setting that restricts a single attempt per order_id for your application.

Security & Signatures

The Return URL access method can be configured manually in your Back Office application settings. For additional security, you can configure Praxis to send signature and timestamp values to your CRM along with the return URL. See the Authentication section for creating the signature. (Note: This is only available when the method is manually set in the Back Office).

2. Dynamic Placeholders

You can dynamically populate your Return URLs using the placeholder variables listed below. This allows your frontend application to parse the incoming URL and display the appropriate success or failure screens to the customer based on the transaction's outcome.

How to Use Placeholders

To use these variables, simply insert them into the return_url string when you make the initialization payment request. Be sure to enclose the variables in double curly braces {{ }}. Praxis will automatically replace these placeholders with the real transaction data before redirecting the customer.

Example API Payload:

{
  "return_url": "https://yoursite.com/return?status={{transaction.transaction_status}}&tid={{transaction.trace_id}}&pin={{customer.pin}}"
}

The data is pulled directly from the information sent during your initialization and the resulting transaction.

⚠️

Data Privacy

For security and compliance purposes, sensitive customer details (such as first name, last name, and date of birth) are intentionally excluded from dynamic Return URLs. Use the {{customer.pin}} variable to map the transaction back to the user securely in your database.

Placeholder variables

Combining Variables for Success/Failure Routing

By combining multiple placeholders, you can build a single return URL that handles both successful and failed payments dynamically.

HTTP GET Example (Query Parameters): If you configure your Return URL as: https://yoursite.com/return?status={{transaction.transaction_status}}&tid={{transaction.trace_id}}

• On Success: The customer is redirected to https://yoursite.com/return?status=approved&tid=12345 (Your frontend displays the Success screen).
• On Failure: The customer is redirected to https://yoursite.com/return?status=rejected&tid=12345 (Your frontend displays the Failure screen).

HTTP POST Example (Path Parameters):
https://yoursite.com/return/{{transaction.transaction_status}}/{{transaction.trace_id}}