Transaction Response

After the customer completes (or fails) a payment on the Hosted Payment Page, they are redirected to your response_url via a GET request. The transaction result is appended as a URL-encoded query string.

This same redirect model is reused by WAPI Trusted Card charge flows, and a close variant is used by Trusted Card create flows. See Hosted Checkout Flows.

The redirect to response_url is the final browser callback for the initial transaction attempt. It is not a substitute for later webhook lifecycle events such as refunds, chargebacks, or confirmed-fraud outcomes. The earlier Payment Request response only creates the checkout session; it does not confirm the payment result.

If you also consume Payments API webhooks, use the redirect to verify the immediate checkout result and use the webhook envelope event for later lifecycle updates.

If the original payment request included data, WiPay echoes that integration-specific string in the response so you can reconcile the result with your own records. See Pass-Through Data.

Response Hash Verification

The hash parameter allows you to verify the authenticity of a successful transaction. It is currently calculated as:

hash = md5(transaction_id + original_total + api_key)

Where:

• transaction_id — the WiPay transaction ID from the response
• original_total — the original transaction total supplied by the requester in the API request, formatted to exactly 2 decimal places (e.g., 10.00). Do not use the customer-facing total value returned in the response parameters.
• api_key — your WiPay account's API Key. Please do not expose your API Key in the public domain.

Critical:

• The hash is only returned for status=success transactions.
• You must always re-calculate and compare the hash on your server before fulfilling any order.
• Since the Payments API request endpoint does not require authentication, response-hash verification is the essential security control that prevents spoofed payment confirmations.
• Your api_key must remain secret and must never be exposed in client-side code, browser-rendered markup, mobile app bundles, or any other public context.
• If a malicious third party obtains the api_key, they can generate matching hashes for forged payment responses, which makes the hash check effectively useless.

As an additional layer of security, you can also use the WAPI Transaction Retrieve endpoint to verify the transaction status directly with WiPay. This should complement the server-side response-hash check, not replace it.

Message Format

The message parameter commonly follows the format [<A>-R<B>]: <C>, but the exact values depend on the hosted checkout configuration behind the transaction.

Some hosted checkout configurations do not expose AVS response details.

Transaction ID Format

The transaction_id commonly follows the format <1><2>-<3>-<4>-<5>.

Example: SB-12-1-oid_123-aBc-20210616024001

Examples

Successful AVS Transaction

A TT platform transaction for 10.00 USD with customer_pay fee structure and AVS enabled:

Failed Transaction

A TT platform transaction for 10.00 USD with merchant_absorb fee structure. Invalid CVV provided:

Note that this failed non-AVS example does not include hash, customer_address, customer_email, or customer_phone.