Skip to main content

Checkout Page

At a glance​

The Checkout Page is a Monek-hosted payment page. You send the customer to it, they pay, and they come back to your site. Card details never touch your servers.

Use the Checkout Page for website checkouts and shopping carts. To keep customers on your own page with embedded card fields, use the Checkout SDK instead. For refunds and repeat charges, use the Payments API.

Try it​

Walk through a Checkout Page payment step by step. This is a simulation: nothing is sent to Monek.

  1. 1Prepare
  2. 2Redirect
  3. 3Pay
  4. 4Result

1. Your server prepares the payment

Enter the order details. Your server sends them to Monek to get a payment token.

Try 25.00 (approved), 75.00 (referred) or 120.00 (declined). These follow the same rules as a Monek test account.

The request your server sends:

POST /Secure/iPayPrepare.ashx HTTP/1.1
Host: elite.monek.com
Content-Type: application/x-www-form-urlencoded

MerchantID=0000000&Amount=2500&CountryCode=826&CurrencyCode=826&MessageType=ESALE_KEYED&Dispatch=NOW&ResponseAction=REDIRECT&ThreeDSAction=ACSDIRECT&SuccessUrl=https%3A%2F%2Fwww.example.com%2Fpayments%2Fsuccess&FailureUrl=https%3A%2F%2Fwww.example.com%2Fpayments%2Ffailure&PaymentReference=ORDER-1001&PreparedPaymentAction=JSON

Before you start​

Testing your integration

Staging is not a sandbox. To test your integration, request a test Merchant ID from support@monek.com. Test Merchant IDs return simulated responses based on the transaction amount. See Test Cards for the expected responses.

Never send real card details to a test Merchant ID, and never use your live Merchant ID for testing on either gateway.

Gateway URLs​

Both gateways are live and will process payments for all Monek merchant accounts. Staging gives early access to new features before they reach the primary platform.

Take a payment​

Step 1: Create a payment token​

Your server sends the payment details to iPayPrepare.ashx and gets back a Prepared Payment token. Doing this server-to-server keeps your merchant and transaction details out of the customer's browser.

Request encoding​

Requests are sent as a standard HTML form submission. Use HTTP POST with a Content-Type of application/x-www-form-urlencoded, with each field name and value URL-encoded in the request body. Query string parameters on an HTTP GET are also accepted, but POST is recommended so that transaction data is not written to browser history or server logs.

JSON and XML request bodies are not supported. The JSON and XML options (ResponseAction and PreparedPaymentAction) only control the format of the response.

The following examples create a Prepared Payment Token for a £10.00 sale and request the token back as JSON:

POST /Secure/iPayPrepare.ashx HTTP/1.1
Host: staging.monek.com
Content-Type: application/x-www-form-urlencoded

MerchantID=0000000&Amount=1000&CountryCode=826&CurrencyCode=826&MessageType=ESALE_KEYED&Dispatch=NOW&ResponseAction=REDIRECT&ThreeDSAction=ACSDIRECT&SuccessUrl=https%3A%2F%2Fwww.example.com%2Fpayments%2Fsuccess&FailureUrl=https%3A%2F%2Fwww.example.com%2Fpayments%2Ffailure&PaymentReference=ORDER-0001&PreparedPaymentAction=JSON

The fields you'll use most are listed under Key fields.

Step 2: Send the customer to the Checkout Page​

Redirect the customer to Checkout.aspx (or CheckoutLite.aspx for a simpler page) with the token in the PaymentToken field. The redirect works with HTTP GET or HTTP POST, and the page can be shown in an iframe.

https://elite.monek.com/Secure/Checkout.aspx?PaymentToken=YOUR_TOKEN

If you show the Checkout Page in an iframe and want Apple Pay, register your domain first.

Step 3: The customer pays​

The customer enters their card details on the Checkout Page. With ThreeDSAction=ACSDIRECT, TransactDirect handles 3-D Secure for you:

  • If the card issuer approves without a challenge (frictionless flow), the payment goes straight to authorisation.
  • If the issuer asks for a challenge, the customer is sent to their bank's authentication page and then straight back.

Step 4: Handle the result​

With ResponseAction=REDIRECT, the customer is sent to your SuccessUrl or FailureUrl with the result in the query string:

https://www.example.com/payments/success?ResponseCode=00&Message=AUTHCODE%3A01223&CrossReference=03050711535801223303
  • ResponseCode 00 means the payment was authorised. Any other code means it wasn't. See Response Code Values.
  • Store the CrossReference. You'll need it for refunds and any later charges.
Confirm orders by webhook

A customer can close their browser before the redirect completes. Set a WebhookUrl so Monek sends the result straight to your server, and use the Integrity Digest to check that results are genuine. See Webhooks.

Key fields​

These are the fields most Checkout Page integrations need.

Looking for a field that isn't here?

The full list of every request and response field is in the Field Reference.

FieldTypical valueNotes
MerchantIDYour 7-digit Monek IDUse your test Merchant ID until you go live.
Amount1000In pence, with no decimal point. 1000 = £10.00.
CurrencyCode826Pound Sterling. See currency codes.
CountryCode826United Kingdom.
MessageTypeESALE_KEYEDAn online sale. See message types.
DispatchNOWUse LATER to authorise now and settle later. See Deferred Dispatch.
ResponseActionREDIRECTSend the customer back to your site with the result.
ThreeDSActionACSDIRECTMonek handles 3-D Secure for you.
SuccessUrl / FailureUrlYour result pagesWhere the customer goes after paying.
PaymentReferenceYour order numberShown in the Monek Portal and returned with the result.
WebhookUrlYour webhook endpointRecommended. See Webhooks.
CardholderNameCustomer's nameNeeded for 3-D Secure.
EmailAddress or PhoneNumberCustomer's email or phoneOne is required for Visa 3-D Secure.

Customise the page​

Add these fields to your payment request to change what the customer sees.

Field NameDescriptionReq'dSizeType
CancelUrlAdds a cancel link to the checkout page which will redirect to the supplied URL.OVA
CancelPromptOverrides the default cancel link label of "Cancel and return to merchant name" with the supplied prompt.OVA
CssIntegrityOptionally allows the contents of CSS URL to be verified using the Subresource Integrity mechanism.
For further information see: https://www.srihash.org/
OVA
CssUrlReferences an external stylesheet to enable merchant customisation of hosted payment page.
If set, this must be a fully qualified URL.
OVA
ShowGooglePayIndicates if the Google Pay™ button will appear on the checkout page. YES or NO (default)

All merchants must adhere to the Google Pay APIs Acceptable Use Policy and accept the terms defined in the Google Pay API Terms of Service. Google Pay is a trademark of Google LLC.
O3A
ShowApplePayIndicates if the Apple Pay button will appear on the checkout page. YES (default) or NO

Note: If hosting the Checkout page in an iFrame you will need to register your domain See: Apple Pay.
O3A
ShowPayPalIndicates if the Pay Pal button will appear on the checkout page. YES or NO (default).

PayPal requires additional merchant configuration, contact Monek Support for details.
O3A
ShowAddressDetailsIndicates whether the address details will be shown on the checkout page. YES (default) or NOO3A
ShowDeliveryAddressIndicates whether the delivery address will be shown on the checkout page. YES or NO (default)O3A
ShowSaveCardShows a "save card details for future use" checkbox on the checkout page. Ticking it is the same as sending AcceptCOF=YES. Options are YES (optional checkbox), MANDATORY (the checkbox must be ticked before the customer can pay) or NO (default).O9 max.A

O = Optional, V = Variable Length, A = Alpha-Numeric

  • Prepared Payments provide a secure way to protect merchant and transaction details with a simple redirect token.
  • Idempotency Tokens provide a reliable way to protect against against duplicate transactions and replay events.
  • The Integrity Digest provides a secure method to verify that responses, redirects, and webhooks are genuine and unmodified.
  • Webhooks provide a simple notification service for transaction results without relying on the cardholder transaction flow.
  • Basket Details provides an updated and flexible method of sending itemised basket details for your transaction that also satisfies required transaction details for American Express.
  • Apple Pay if you want to embed our checkout page in an iframe on your website, you will need to register your domain in order for Apple Pay to function.

Go-live checklist​

  • Swap your test Merchant ID for your live one.
  • Create payments with Prepared Payments so transaction details stay off the customer's browser.
  • Set a WebhookUrl and confirm orders from the webhook, not only the redirect.
  • Check your SuccessUrl and FailureUrl point at your live site over https.
  • Send CardholderName, and EmailAddress or PhoneNumber, so 3-D Secure works smoothly.
  • If you use an iframe with Apple Pay, register your domain.