Integrating iPay88 with ASP.NET MVC Around Verified Transactions

Editorial illustration.

Originally published 23 June 2023; rewritten and reviewed on 15 October 2026.

A payment gateway introduces two conversations: the customer’s browser journey and the server’s conversation about money. They may finish at different times. I would design the local order state so either conversation can be interrupted without inventing a successful payment.

Work from the merchant specification

Obtain the current iPay88 integration documentation for the merchant account, payment product and environment. Confirm endpoints, field ordering, amount representation, character encoding and signature verification directly from that specification.

Do not assume a digest copied from an older article remains the correct algorithm. Never place the merchant secret in JavaScript or use client-submitted totals as the authoritative order amount.

Give the order a stable reference

Persist a local order and its expected currency and amount before redirecting the buyer. Use a reference that can be matched to the provider response and checked against the authorised merchant account.

The server-side result handler should establish:

  1. The notification passed the provider’s documented authenticity checks.
  2. Its merchant and order identifiers belong to the expected transaction.
  3. The amount, currency and payment status match the intended transition.
  4. The same event has not already fulfilled the order.

The browser return can ask the server for that stored state. It should not create a paid state merely because a user opened the return URL.

Exercise operational failures

Test cancellation, a delayed notification, a duplicate delivery and a timeout after the customer completes payment. Provide a support procedure for reconciling uncertain results through the provider’s supported channels.

Keep logs useful without exposing secrets or unnecessary payment details. A professional integration makes the money movement traceable while keeping the customer-facing explanation simple: paid, pending, cancelled or failed, according to evidence the server has actually verified.

Related reading