Requesting a Hosted Checkout interaction is a simple process:
Initiate Checkout operation. The request should include payment and interaction data, as well as completion instructions. A sample curl snippet for the Initiate Checkout operation is shown below.
curl https://na.gateway.mastercard.com/api/nvp/version/70 \ -d "apiOperation=INITIATE_CHECKOUT" \ -d "apiPassword=$PWD" \ -d "apiUsername=merchant.<your_merchant_id>" \ -d "merchant=<your_merchant_id>" \ -d "interaction.operation=AUTHORIZE" \ -d "interaction.merchant.name=<your_merchant_name>" \ -d "order.id=<unique_order_id>" \ -d "order.amount=100.00" \ -d "order.currency=USD" \ -d "order.description=<description_of_order>"
A successful response to this operation will contain session.id and successIndicator parameters. You can save the value returned in the successIndicator parameter on your shop system to verify the success or failure of the payment. See Obtaining the Payment Result.
Checkout object into global scope.
<script src="https://na.gateway.mastercard.com/static/checkout/checkout.min.js" data-error="errorCallback" data-cancel="cancelCallback"></script>
checkout.js Reference[JavaScript]
Checkout.configure(), passing in a JSON object that includes the returned session.id and other request parameters.
Checkout.configure({
session: {
id: '<your_initiate_checkout_ID>'
},
interaction: {
merchant: {
name: 'Your merchant name',
address: {
line1: '200 Sample St',
line2: '1234 Example Town'
}
}
}
});
Checkout.configure() will never overwrite data you provided in the Initiate Checkout operation.Checkout.showEmbeddedPage('#embed-target')
Checkout.showPaymentPage()
<html>
<head>
<script src="https://na.gateway.mastercard.com/static/checkout/checkout.min.js" data-error="errorCallback" data-cancel="cancelCallback"></script>
<script type="text/javascript">
function errorCallback(error) {
console.log(JSON.stringify(error));
}
function cancelCallback() {
console.log('Payment cancelled');
}
Checkout.configure({
session: {
id: '<your_initiate_checkout_session_ID>'
}
});
</script>
</head>
<body>
...
<div id="embed-target"> </div>
<input type="button" value="Pay with Embedded Page" onclick="Checkout.showEmbeddedPage('#embed-target');" />
<input type="button" value="Pay with Payment Page" onclick="Checkout.showPaymentPage();" />
...
</body>
</html>
Checkout.configure() as:quantity : 300quantity : function() { return 100 + 200 }. Functions are executed when the payment process is triggered.
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css" integrity="sha384-JcKb8q3iqJ61gNV9KGb8thSsNjpSL0n8PARn9HuZOnIxN0hoP+VmmDGMN5t9UJ0Z" crossorigin="anonymous">
<title>Hello, world!</title>
</head>
<body>
<h1>Hello, world!</h1>
<button type="button" class="btn btn-primary" data-toggle="modal" data-target="#exampleModal">
Launch demo modal
</button>
<div class="modal fade" id="exampleModal" tabindex="-1" role="dialog" aria-labelledby="exampleModalLabel" aria-hidden="true">
<div class="modal-dialog" role="document">
<div class="modal-content">
<div class="modal-header">
<h5 class="modal-title" id="exampleModalLabel">Modal title</h5>
<button type="button" class="close" data-dismiss="modal" aria-label="Close">
<span aria-hidden="true">×</span>
</button>
</div>
<div class="modal-body" id="hco-embedded">
</div>
<div class="modal-footer">
<button type="button" class="btn btn-secondary" data-dismiss="modal">Close</button>
<button type="button" class="btn btn-primary">Save changes</button>
</div>
</div>
</div>
</div>
<script src="https://code.jquery.com/jquery-3.6.0.slim.min.js" integrity="sha256-u7e5khyithlIdTpu22PHhENmPcRdFiHRjhAuHcs05RI=" crossorigin="anonymous"></script>
<script src="https://cdn.jsdelivr.net/npm/bootstrap@4.5.2/dist/js/bootstrap.min.js" crossorigin="anonymous"></script>
<script src="https://na.gateway.mastercard.com/static/checkout/checkout.min.js" ></script>
<script>
// Configure Checkout first
Checkout.configure({
session: {
id: "SESSION123123123"
}
})
// after the modal is shown, then call Checkout.showEmbeddedPage('#hco-embedded')
$('#exampleModal').on('shown.bs.modal', function (e) {
Checkout.showEmbeddedPage('#hco-embedded')
});
</script>
</body>
</html>
<script src="https://na.gateway.mastercard.com/static/checkout/checkout.min.js"
data-cancel="cancelCallback"
data-beforeRedirect="Checkout.saveFormFields"
data-afterRedirect="Checkout.restoreFormFields">
</script>
<script>
function cancelCallback() {
confirm('Are you sure you want to cancel?');
// code to manage payer interaction
}
// or if you want to provide a URL:
// cancelCallback = "someURL"
</script>
Callbacks are provided to handle events that may occur during the payment interaction.
Use of callbacks is optional, but you must define those you need in the body of the same <script> tag that references checkout.js.
All defined callbacks must have an implementation. They will be invoked when the relevant event is triggered.
Basic callbacks are provided for handling the following events:
cancel: When the payer cancels the payment interaction.
error: When an error is encountered. complete: When the payer completes the payment interaction. timeout: When the payment is not completed within the duration available to the payer to make the payment. These can be functions or URLs. If you provide a URL instead of a function in a callback, the payer will be redirected to this URL when the event is triggered.
Since Hosted Checkout supports payment interactions that require the payer to be redirected away to other websites to progress the payment (e.g. PayPal), callbacks are provided to manage what happens before the redirect and after return to Hosted Checkout to finalize transaction processing.
beforeRedirect: Before the payer is presented with the payment interface. Returns data required to restore page state for use by afterRedirect.afterRedirect: When the payer returns from completing the payment interaction. Uses the data saved by beforeRedirect to return the saved payment interface state.The Checkout object also provides two functions to help you implement the beforeRedirect and afterRedirect callbacks:
saveFormFields: Saves all current form fields for use by restoreFormFields. Use in your beforeRedirect implementation or implement beforeRedirect as Checkout.saveFormFields. restoreFormFields: Restores form fields saved by saveFormFields. Use in your afterRedirect implementation or implement afterRedirect as Checkout.restoreFormFields. checkout.js Reference[JavaScript]
After the payment interaction completes, you can return the payer to your shop site and present your own receipt page to the payer. You can also update your shop system with the payment details.
To return the payer to your shop site, you must either:
interaction.returnUrl in the Initiate Checkout operation, ORcomplete callback in the Hosted Checkout request. This applies to both basic and redirect callbacks. See Callbacks.The gateway sends the result of the payment in a resultIndicator parameter, which is either:
interaction.returnUrl) used for returning the payer to your shop site, ORcomplete callback or appended to the URL provided in the complete callback.You can determine the success of the payment by comparing the resultIndicator parameter to the successIndicator parameter returned in the Initiate Checkout response. A match indicates that the payment has been successful.
resultIndicator parameter must never be used as the receipt number.If successful, present a payment receipt to the payer on your shop site, and update your shop system with the payment details. You can retrieve these using the Retrieve Order operation.
The payment details are recorded in Merchant Administration in the Order and Transaction Details page. You can search for the payment and also perform subsequent operations.
If you subscribe to Reporting, you can download Hosted Checkout payment data in a formatted report from the Mastercard Payment Gateway.
If you subscribe to email notifications in Merchant Administration, you will receive an email notification for every successful payment.
Hosted Checkout allows you to control the display of information about your business and the interaction with the payer using either the Initiate Checkout operation or the Checkout.configure() method. Note that data provided in the Initiate Checkout request will always take precedence over data provided in the Checkout.configure() method. For enhanced security, it's recommended that you provide data in a session using the Initiate Checkout operation.
| URL | https://na.gateway.mastercard.com/api/rest/version/70/merchant/{merchantId}/session |
| HTTP Method | POST |
{
"apiOperation": "INITIATE_CHECKOUT",
"interaction": {
"operation": "AUTHORIZE"
},
"order" : {
"amount" : "122.0",
"currency" : "USD",
"description": "Ordered goods",
"id": "232E32323ddd"
}
}
Checkout.configure({
session: {
id: '<your_initiate_checkout_ID>'
},
billing : {
address: {
street : '123 Customer Street',
city : 'Metropolis',
postcodeZip : '99999',
stateProvince: 'NY',
country : 'USA'
}
},
interaction: {
merchant : {
name : 'Your merchant name',
address: {
line1: '200 Sample St',
line2: '1234 Example Town'
},
email : 'order@yourMerchantEmailAddress.com',
phone : '+1 123 456 789 012',
logo : 'https://imageURL'
},
locale : 'en_US',
style: {
theme: 'default'
},
displayControl: {
billingAddress : 'OPTIONAL',
customerEmail : 'OPTIONAL',
shipping : 'HIDE'
}
}
});
interaction.merchant parameter group will be displayed on the receipt page for the Hosted Payment Page integration only, not for the Embedded Page. This includes your logo as well as contact details.
For more details see:
After collecting billing and email addresses from your payer, you can display these and control their editability by setting interaction.displayControl.billingAddress and interaction.displayControl.customerEmail fields to one of the following:
HIDE: If you do not want Hosted Checkout to display the fields.MANDATORY: If you want Hosted Checkout to display the fields and make data entry compulsory for the payer. OPTIONAL: If you want Hosted Checkout to display the fields, but allow the payer to opt out of entering data into them.READ_ONLY: If you want Hosted Checkout to display the fields, but not allow the payer to edit them.After collecting shipping details from your payer, you can control their display by setting interaction.displayControl.shipping field to one of the following:
HIDE: If you do not want Hosted Checkout to display the fields.READ_ONLY: If you want Hosted Checkout to display the fields, but not allow the payer to edit them.By default, the language displayed with Hosted Checkout is determined from the payer's browser. However, you can override this behavior by specifying a language identifier or IETF language tag in the locale field; e.g. en_US, es, fr_CA. If the language you specify is not supported by the Mastercard Payment Gateway, Hosted Checkout is displayed in the best matching language.
By default, the theme set as default by your payment service provider controls the look and feel of Hosted Checkout. If your payment service provider supports multiple themes, you can choose to override the default theme by providing interaction.style.theme field in your request.
The theme available for you at this time is default.
It is recommended that you include order.id in your request to easily identify a payment initiated from Hosted Checkout. You can use an identifier generated by your shopping cart or supply your own. However, ensure that it is unique.
When a payer chooses to pay using their card, they can enter either Credit or Debit card details during the checkout interaction. However, if at least one of your acquirers supports combo cards, i.e., cards that can be used either as a debit or credit card, the payer will be required to make a payment method selection on the payment page — Debit Card or Credit Card — to specify the mode the card should operate in for this payment.
To use 3-D Secure authentication with your hosted checkout integration, contact your payment service provider to enable the necessary privileges for your merchant account.
To test your integration is functioning with 3-D Secure authentication, you can use your TEST merchant profile in the Production environment.
Use the following test cards to test the integration
| Card type | Authentication status | Test card |
|---|---|---|
| Mastercard | 3DS2 - Challenge | 5123450000000008 |
| Mastercard | 3DS1 - Not enrolled for 3DS2 resulting in fallback to 3DS1 | 5506900140100305 |
| Visa | 3DS2 - Challenge | 4440000009900010 |
| Visa | 3DS1 - Not enrolled for 3DS2 resulting in fallback to 3DS1 | 4508750015741019 |
For further information regarding authentication, see Authentication FAQs.
Hosted Checkout may be configured to provide a user experience compliant with WCAG 2.0 Level AA. See WCAG 2.0 guidelines and ensure your website conforms to this technical standard.
Add lang attribute to the html element.
<html lang="en">
<head></head>
<body></body>
</html>
If you have payment plans configured on your merchant profile, by default all payment plans on your merchant configuration will be displayed to the payer during Hosted Checkout. However, payment plans available to the payer will be determined by the card number entered by the payer and the currency for the order.
You can limit payment plans available on offer by specifying constraints on payment plans on a per transaction basis. This is useful if you wish to ensure that payment options offered to the payer conform to pre-defined criteria thereby preventing payment processing if the payer tampers with the payment plan data. You can use the following fields in the request to specify constraints:
constraints.paymentPlans.supported[n]: The payment plans offered for this transaction.constraints.paymentPlans.numberOfPayments: The allowable number of installments for the payment plan.constraints.paymentPlan.numberOfDeferrals: The allowable number of deferral months for the payment plan.By default, the payment terms for a payment plan, if available, are displayed on Hosted Checkout. You can hide them by setting interaction.displayControl.paymentTerms=HIDE in Checkout.configure().
For gift cards and Automated Clearing House payments, Hosted Checkout only supports payment details verification.
You can do this by setting interaction.operation=VERIFY in the Initiate Checkout request.
Hosted Checkout uses the verification methods supported by the configured acquirer and the data provided in the request.
You can determine the success of the verification operation by comparing resultIndicator to successIndicator.
If the interaction was not successful, Hosted Checkout displays a message indicating that verification has failed and prompts the payer to try again.
You can use Hosted Checkout with any transaction source configured on the merchant profile (Internet, Call Centre, Telephone Order, etc).
You can do this by providing transaction.source in the Initiate Checkout request.
If a Hosted Checkout is requested with transaction.source other than INTERNET, payment options that require the payer to be present will not be supported.
If you do not provide transaction.source in the request:
INTERNET if supported on the merchant-acquirer link.You can control whether payers are required to provide the Card Security Code to process the payment by setting interaction.displayControl.cardSecurityCode in the Initiate Checkout request to one of the following values:
OPTIONAL: If you want Hosted Checkout to display the Card Security Code input field but input to this field is not mandatory.MANDATORY (default): If you want Hosted Checkout to display the Card Security Code input field and make it mandatory.If you are configured for 3-D Secure authentication or a risk management service, you have the option to bypass these should you wish to do so.
interaction.action.3DSecure=BYPASS in the Initiate Checkout request. The interaction.action.3DSecure field in the CREATE_CHECKOUT_SESSION request can take values:
risk.bypassMerchantRiskRules=ALL in the Initiate Checkout request. Before going live, you must test your integration to ensure correct functionality.
Hosted Checkout can return a number of integration errors. See Test Your Integration.
An error page is provided when an incorrect Hosted Checkout request is attempted. Common causes for errors include:
If the payer double submits the "Pay" button, the transaction will not be repeated with your or the payer's bank.
Yes, Edge 18 is supported.
The Hosted Checkout model is secure as it requires you to authenticate to the gateway, and the payment details collected on the payment page are submitted directly from the payer's browser to the gateway.
There are no restrictions on the file size or logo width. As for height, the minimum recommendation is 144 px.
Yes, you can host your logo image on any provider, however; it's mandatory that the URL is secure (HTTPS). If your hosted provider does not support a secure URL, here's a list of providers that can offer you free HTTPS hosting: https://www.google.com.au/search?q=secure+image+hosting+providers
This checkbox is visible only if all required fields in the shipping address have been provided. You must ensure that either the payer has completed these, or that you supply any missing ones (such as shipping.country, in the case where goods are not being shipped internationally).
If you would like to offer your customers a good mobile experience including optimizing your Hosted Checkout experience on mobile, it is a best practice to add a 'viewport' meta tag to your site's page. For example,
<meta name="viewport" content="width=device-width, initial-scale=1">
Please note that it's important to choose the right viewport values for your pages and to test your own site with these changes.
Copyright © 2022 Mastercard