# Hosted Checkout > Testing Steps
source: https://developer.mastercard.com/mastercard-gateway/documentation/testing/test-your-int/hosted-checkout/index.md

Careful testing is the cornerstone of software development, ensuring it operates as expected. You cannot move on to a live environment and handle real payments until you have confirmed that your integration works as desired in all scenarios.

Prerequisites
Before you start testing your Hosted Checkout integration, you must complete:

* \[Basic integration\] using the Hosted Payment Page to gather payment details.
* Integration for any \[subsequent Operations\] you want to handle within your order lifecycles.
* Any customizations related to the [payment methods](https://developer.mastercard.com/mastercard-gateway/documentation/payment-methods/index.md) you want to support.
* All additional \[features\] and \[security-related functionality\] you need.

## Testing your integration {#testing-your-integration}

Cover at least the following steps in your testing:

* For the payment methods you support, test all individual Operations you want to use in your integration where payer interaction is needed on the Hosted Payment Page.  
  Test the process from creating the checkout session to providing the Hosted Payment Page to the payer and managing the callbacks from the payment page process.
* For the payment methods you support, determine the payment flows (combinations of initial and subsequent transactions) you want to be able to use in your integration. Test all the flows with all possible combinations of subsequent transactions.
* Test all the additional features and security-related functionality that you are using.
* Confirm that your system reacts appropriately and overcomes all common error scenarios related to invalid requests and server problems.  
  For examples of error scenarios to be considered, see \[Common Transaction Failures\].
* Determine the transaction responses that require further actions from you, and test that your integration is taking expected actions.

## Testing tools {#testing-tools}

To test your integration, the Mastercard Gateway provides some helpful tools:

* **Simulators**
  You can test your requests using various simulators, which you can access from your test merchant account. To confirm that you are using your test merchant account, check that the merchant ID supplied by your payment service provider (PSP) has the prefix "TEST". All requests sent with the test merchant ID are regarded test requests and handled by the simulators. They are not sent forward to actual providers, issuers, and acquirers.

  Warning: If you have already been given a merchant ID that has the "TEST" prefix, that is your test merchant account. Your PSP sends you another merchant ID when you are ready to process live transactions. The test merchant account is a wholly separate account with a different API password or certificates from your regular account. When switching from one to the other, make sure to change both your merchant ID and any authentication credentials. For the payment methods that require the payer to provide their approval on the payment provider's web site, the gateway provides an interactive payment simulator. For more information on specific simulator features and options, see the test instructions on specific [payment methods](https://developer.mastercard.com/mastercard-gateway/documentation/payment-methods/index.md) and \[Common Browser Payment Integration\].

  <br />

* **Test cards**
  If you support card payments as payment methods, the gateway provides test cards to enable you to test various scenarios, including EMV 3-D Secure authentication. For details, see \[Test Cards\] and \[Testing Your Integration for EMV 3-D Secure Authentication\].

* **Predictable response results**
  The test simulator is configured to generate predictable results based on the transaction request and the card details you supply. For details, see \[Test Cards\] and \[Common Browser Payment Integration\].
  You can trigger transaction responses that contain a specific Mastercard Gateway Response Code or Card Security Code validation result, as well as Address verification Response Code, and ensure that your integration reacts appropriately to each. You can also receive specific response results for features like \[wallets\].

## Common transaction failures {#common-transaction-failures}

When testing your integration, consider the following transaction failure scenarios and make sure that your system reacts to them appropriately:

* **Payment authorization declined or card type not accepted**
  If the `response.gatewayCode` in your transaction response has a value starting with DECLINED, the payment authorization has not been approved by the issuing bank or the payer is attempting to use a card type that is not accepted by the gateway.
  Study the exact returned gateway code and other details in the transaction to determine in more detail why the payment has been declined. You may need to ask the payer to use a different payment method to solve the problem.

* **Invalid card information**
  If the `response.gatewayCode` in your transaction response is set to INVALID_CSC, EXPIRED_CARD, or similar, the problem is with the payer's card details. The payer has either entered them incorrectly, or the card is no longer valid. You need to ask the payer to check their card details or potentially use a different card.

* **Insufficient funds**
  If the `response.gatewayCode` in your transaction response is set to INSUFFICIENT_FUNDS, the payer's account does not have enough funds to cover the transaction. You need to ask the payer to use a different payment method or card.

* **Transaction timeout**
  If the `response.gatewayCode` in your transaction response is set to TIMED_OUT, the gateway did not receive an answer from the acquirer. Consequently, the transaction was automatically terminated. You need to try again later.