---
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
082018Adyen Test4111111111111111 // 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.