# Test data

Sample customers and payment details for every market in the Kustom playground, plus eight end-to-end test cases that prove an integration's order lifecycle closes before go-live. Never test with real personal data.

Everything here works in the Kustom **playground** environment only, and none of it moves
money. Use it to complete checkouts end to end while you build. Don't test with real
customer data — these addresses and payment details exist so you never have to.

## Sample customer data

Use the row for the market you're testing. `NIN` is the national identification number,
required only where listed.

| Country | Post number | Address | City | Phone number | Date of birth | NIN |
|---|---|---|---|---|---|---|
| Austria | 1060 | Mariahilfer Straße 47 | Wien | 0676 260 0456 | 31.07.1981 | — |
| Belgium | 1000 | Grote Markt 1 | Brussel | 0485 121 291 | 16/05/1984 | — |
| Czech Republic | 155 00 | Zazvorkova 1480/11 | Praha | 077 161 3715 | 04.03.1984 | — |
| Denmark | 1556 | Dantes Plads 7 | København Ø | 42 55 56 28 | 08/07/1977 | 120153-0683 |
| Finland | 00100 | Mannerheimintie 34 | Helsinki | 040 123 4567 | 04/04/1974 | 040474-1048 |
| France | 75009 | 33 rue la Fayette | Paris | 06 89 85 43 21 | 27/10/1996 | — |
| Germany | 10178 | Neue Schönhauser Str. 2 | Berlin | 0176 1428 4340 | 24.05.1975 | — |
| Greece | 151 23 | Kephisias 37 | Athina | 69 4555 3624 | 02/01/1973 | — |
| Ireland | D02 C838 | 30 King Street South | Dublin | 085 535 1400 | 10/09/1987 | — |
| Italy | 00146 | Via Enrico Fermi 150 | Roma | 333 974 1231 | 12/09/1972 | — |
| Netherlands | 1068 SR | Osdorpplein 137 | Amsterdam | 06 89 12 43 21 | 10-05-2004 | — |
| Norway | 0194 | Edvard Munchs Plass 1 | Oslo | 40 12 34 56 | 03/09/1971 | 110779-41012 |
| Poland | 01-460 | Ul. Górczewska 124 | Warszawa | 795 222 223 | 04/06/2001 | — |
| Portugal | 1990-094 | Avenida Dom João II 40 | Lisboa | 935 556 731 | 20/01/1994 | — |
| Spain | 28012 | C. de Atocha, 27 | Madrid | 67 256 3009 | 08/08/1968 | — |
| Sweden | 111 48 | Södra Blasieholmshamnen 2 | Stockholm | 070 174 06 15 | 09/08/1976 | 19760809-1844 |
| Switzerland | 4051 | Augustinergasse 2 | Basel | 075 868 00 00 | 26.10.2001 | — |
| United Kingdom | W1S 3BE | 10 New Burlington Street, Apt. 214 | London | 07755 564 318 | 15/11/1998 | — |

## Sample business data

For B2B flows, use any customer row above and set the organization number to
`556131-2058`. B2B purchases settle through Billie, listed under payment data below.

## Sample payment data

These complete a payment inside the Kustom widget. All are playground-only.

### Card

| Field | Value |
|---|---|
| Credit card number | `4242 4242 4242 4242` |
| Debit card number | `4000 0566 5566 5556` |
| Card triggering 3-D Secure | `4000 0027 6000 3184` |
| CVC | `123` |
| Expiry | `12/34`, or any future date in `MM/YY` |

In the United States the debit card is also what tests financing. When prompted for a
Social Security Number, use `123456789`.

### Direct debit

Use an IBAN-format number. For a German test store, `DE11 5205 1373 5120 7101 31` works.
In Sweden, use the personal number `19770111-6050`.

### Direct bank transfer

Choose **Demo Bank** in the Kustom widget and follow its prompts.

### Billie (B2B)

Use the organization number under sample business data above, with any customer row for
the market you're testing.

## End-to-end test cases

Run these eight cases end to end in the playground before you ask for production keys, and
keep them as your regression suite afterwards. They cover the four stages of the order
lifecycle — purchase, pre-shipment, shipment, post-shipment — and between them exercise every
money movement your integration can make. Skip any case that doesn't apply to your store: if
you never issue partial refunds, don't test them.

| # | Cart | What you do | Expected status in the Portal |
| --- | --- | --- | --- |
| 1 | 1 item | Place, capture in full, refund in full | Fully Captured and Fully Refunded |
| 2 | 2 items, added in two visits to the checkout | Place, capture in full, refund 1 item | Fully Captured and Partially Refunded |
| 3 | 2 items | Place, capture 1 item, release the remaining authorization | Fully Captured |
| 4 | 1 item with a discount code | Place, capture in full, refund in full | Fully Refunded, with the discount visible on the order lines |
| 5 | 2 items with a gift card | Place, capture in full, refund 1 item | Fully Captured and Partially Refunded |
| 6 | 1 item | Place, then cancel before capturing | Cancelled |
| 7 | 1 item, different billing and shipping addresses | Place only | Order created, with two distinct addresses on the Customer panel |
| 8 | 1 item plus a paid shipping option | Place only | Order created, with a `shipping_fee` order line |

Each run follows the same shape. Add the product or products to the cart, go to the
checkout, place the order with the data above and confirm you land on your confirmation page.
Then open **Orders** in the Portal, find the order and check on the **Order lines** tab that
product name, unit price, tax and amount are what you sent. Capture, refund, cancel or
release from your own system where you have one, or from the Portal where you don't —
manual Portal steps are only reliable when your integration isn't linked to an external
system, because the Portal status won't be synchronized with it.

Cases 2 and 4 are worth extra attention: case 2 also checks that the cart stays correct when
the customer navigates between the checkout and product pages, and case 4 checks that a late
discount doesn't break tax reconciliation.

### Check the order in Developer Logs

Portal statuses tell you the money moved. Developer Logs tell you the order was rich enough
to be useful. Open **Logs** in the playground Portal, search the Kustom order id from the
order's **Summary** tab and check the requests against this table, with the [Checkout API
reference](/api/checkout/) open alongside.

| Order characteristic | Cases | Expected in the logs |
| --- | --- | --- |
| Any placed order | 1–8 | `order_lines` entries carry `product_url` and `image_url` |
| A refund | 1, 2, 4, 5 | The response header carries the refund's URI and id |
| A discount code | 4 | Either a separate `order_line` of type `discount` with a negative amount, or `total_discount_amount` set per line |
| A gift card | 5 | A separate `order_line` of type `gift_card` with a negative amount |
| Different billing and shipping addresses | 7 | `billing_address` and `shipping_address` differ, matching what you entered |
| A shipping fee | 8 | A separate `order_line` of type `shipping_fee` with the correct amount |

## Related

- [Authentication and environments](/api/authentication/) — get a playground key first, and
  production keys once these cases pass
- [Capture an order](/order-management/capture/) and
  [Refunds](/order-management/refunds/) — the operations cases 1 to 5 depend on
- [Troubleshooting Checkout](/checkout/troubleshooting/) — decode what a failing case is
  telling you
- [Checkout in 15 minutes](/checkout/quickstart/) — somewhere to spend this data