--- title: "Testing Hosted Payment Pages" url: "https://docs.adyen.com/online-payments/classic-integrations/hosted-payment-pages/testing" source_url: "https://docs.adyen.com/online-payments/classic-integrations/hosted-payment-pages/testing.md" canonical: "https://docs.adyen.com/online-payments/classic-integrations/hosted-payment-pages/testing" last_modified: "2019-04-30T01:18:00+02:00" language: "en" --- # Testing Hosted Payment Pages [View source](/online-payments/classic-integrations/hosted-payment-pages/testing.md) **Hosted Payment Pages are no longer available** To accept payments through an Adyen-hosted page, use our [Hosted Checkout](/online-payments/build-your-integration/sessions-flow?platform=Web\&integration=Hosted%2BCheckout). This page is for the classic Hosted Payment Pages (HPP) integration, which has reached end-of-life. We are no longer processing transactions though HPP. ## AVS You can use a set of [test card numbers and test accounts](/development-resources/test-cards-and-credentials/test-card-numbers) for QA purposes and to verify that your implementation works as expected. You can test all available AVS result codes. To do so, you can use the `billingAddress.street` and the `billingAddress.houseNumberOrName` fields in a standard payment request form to submit the AVS code data you want to check. ```xml ``` ###  Test AVS result codes | AVS Response code | Description | | ----------------- | --------------------------------------------------------- | | 0 | Unknown. | | 1 | Address matches, but the postal code does not match. | | 2 | Neither postal code nor address match. | | 3 | AVS unavailable. | | 4 | AVS not supported for this card type. | | 5 | No AVS data provided. | | 6 | Postal code matches, but the address does not match. | | 7 | Both postal code and address match. | | 8 | Address not checked, postal code unknown. | | 9 | Address matches, postal code unknown. | | 10 | Address doesn't match, postal code unknown. | | 11 | Postal code not checked, address unknown. | | 12 | Address matches, postal code not checked. | | 13 | Address doesn't match, postal code not checked. | | 14 | Postal code matches, address unknown. | | 15 | Postal code matches, address not checked. | | 16 | Postal code doesn't match, address unknown. | | 17 | Postal code doesn't match, address not checked. | | 18 | Neither postal code nor address were checked. | | 19 | Name and postal code matches. | | 20 | Name, address and postal code matches. | | 21 | Name and address matches. | | 22 | Name matches. | | 23 | Postal code matches, name doesn't match. | | 24 | Both postal code and address matches, name doesn't match. | | 25 | Address matches, name doesn't match. | | 26 | Neither postal code, address nor name matches. | ## CVV-CVC results To test CVC/CVV result codes on HPP, you need to prefix the code number you want to test with two padding zeroes:\ 00{CVCCCVcode} For example, to test CVC/CVV result code 4 No CVC/CVV provided, enter it as  004 in the CVV field on the HPP. You can test CCV/CVV result codes. Assign the appropriate values to the child elements of the card element, as described below: | Parent | Child | Value to test CVC/CVV | | ---------- | ------------ | ---------------------------------------------------------------------------------------------------------------- | | **`card`** |   |   | |   | **`number`** | *\* | |   | **`cvc`** | *\* | You still need to include and define all the other `card` child elements, but their values do not impact the `cvc` return value you want to test. You can use a [test card number with a CVC from this list](/development-resources/test-cards-and-credentials/test-card-numbers) to test CVC/CVV results. ### Card examples The following examples show how to use the `card` element to test specific CVC/CVV result codes. #### JSON ```json { "card" : { "number" : "4111111111111111", // Use a test card number that has a CVC number "cvc" : "737", // Use padding zeroes as necessary before the 1- or 2-digit CVC-CVV code you want to test "expiryMonth" : "08", "expiryYear" : "2018", "holderName" : "Adyen Test" } } ``` #### Soap ```xml 737 // Use padding zeroes as necessary before the 1- or 2-digit CVC-CVV code you want to test 08 2018 Adyen Test 4111111111111111 // Use a test card number that has a CVC number ``` ### CVC-CVV result codes | | CVC/CVV result code | Result | | - | ------------------------------------- | -------- | | 0 | Unknown | Approval | | 1 | Matches | Approval | | 2 | Doesn't match | Decline | | 3 | Not checked | Approval | | 4 | No CVC/CVV provided, but was required | Decline | | 5 | Issuer not certified for CVC/CVV | Approval | | 6 | No CVC/CVV provided | Approval | ## Result codes You can test refused transactions and the specific refusal reason that are returned when a transaction fails. Make an [/authorise](https://docs.adyen.com/api-explorer/#/Payment/latest/authorise) request, and include the required `card` fields (you can use one of the test card numbers with a CVC from [this list](/development-resources/test-cards-and-credentials/test-card-numbers)). For the `holderName`, include a value with the following: * a **Response** from the list of [Adyen response codes](/development-resources/testing/result-codes#values-for-testing-result-reasons). * a [Scheme Response code and Refusal reason raw String](/development-resources/raw-acquirer-responses). For this value, use the format: ``` [Adyen Response code] : [Scheme Response code and Refusal reason raw String] ``` You may need to lower the risk score value to take into account non-alphabetic characters in the cardholder name like a colon (":"). This and other non-alphabetical characters trigger the risk check, which may cause the payment to be declined with a `FRAUD` reason code. ### Example The following example shows how you test a "Declined" payment result due to an "Error", using the `holderName`: ``` DECLINED : 06 : ERROR ``` * The `holderName` field value cannot be longer than 80 characters max. * If you specify an incorrect CVC or an invalid expiry date, the payment fails and the operation returns a generic `DECLINED` refusal reason. ## Testing chargebacks To test a chargeback, create a payment and enter **Chargeback **in the `card.holderName`** **field. This simulates a flow for a chargeback. The payment goes through the normal process for authorisation and settlement. After settlement, the chargeback is initiated. ## Testing chargeback reversed Create a payment and enter **Chargeback Reversed** in the `card.holderName` field. The payment goes through the normal process for authorisation and settlement. After settlement, the chargeback is reversed.