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
Section titled “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 |
|---|---|---|---|---|---|---|
| ATAustria | 1060 | Mariahilfer Straße 47 | Wien | 0676 260 0456 | 31.07.1981 | — |
| BEBelgium | 1000 | Grote Markt 1 | Brussel | 0485 121 291 | 16/05/1984 | — |
| CZCzech Republic | 155 00 | Zazvorkova 1480/11 | Praha | 077 161 3715 | 04.03.1984 | — |
| DKDenmark | 1556 | Dantes Plads 7 | København Ø | 42 55 56 28 | 08/07/1977 | 120153-0683 |
| FIFinland | 00100 | Mannerheimintie 34 | Helsinki | 040 123 4567 | 04/04/1974 | 040474-1048 |
| FRFrance | 75009 | 33 rue la Fayette | Paris | 06 89 85 43 21 | 27/10/1996 | — |
| DEGermany | 10178 | Neue Schönhauser Str. 2 | Berlin | 0176 1428 4340 | 24.05.1975 | — |
| GRGreece | 151 23 | Kephisias 37 | Athina | 69 4555 3624 | 02/01/1973 | — |
| IEIreland | D02 C838 | 30 King Street South | Dublin | 085 535 1400 | 10/09/1987 | — |
| ITItaly | 00146 | Via Enrico Fermi 150 | Roma | 333 974 1231 | 12/09/1972 | — |
| NLNetherlands | 1068 SR | Osdorpplein 137 | Amsterdam | 06 89 12 43 21 | 10-05-2004 | — |
| NONorway | 0194 | Edvard Munchs Plass 1 | Oslo | 40 12 34 56 | 03/09/1971 | 110779-41012 |
| PLPoland | 01-460 | Ul. Górczewska 124 | Warszawa | 795 222 223 | 04/06/2001 | — |
| PTPortugal | 1990-094 | Avenida Dom João II 40 | Lisboa | 935 556 731 | 20/01/1994 | — |
| ESSpain | 28012 | C. de Atocha, 27 | Madrid | 67 256 3009 | 08/08/1968 | — |
| SESweden | 111 48 | Södra Blasieholmshamnen 2 | Stockholm | 070 174 06 15 | 09/08/1976 | 19760809-1844 |
| CHSwitzerland | 4051 | Augustinergasse 2 | Basel | 075 868 00 00 | 26.10.2001 | — |
| GBUnited Kingdom | W1S 3BE | 10 New Burlington Street, Apt. 214 | London | 07755 564 318 | 15/11/1998 | — |
Sample business data
Section titled “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
Section titled “Sample payment data”These complete a payment inside the Kustom widget. All are playground-only.
| 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
Section titled “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
Section titled “Direct bank transfer”Choose Demo Bank in the Kustom widget and follow its prompts.
Billie (B2B)
Section titled “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
Section titled “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
Section titled “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 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
Section titled “Related”- Authentication and environments — get a playground key first, and production keys once these cases pass
- Capture an order and Refunds — the operations cases 1 to 5 depend on
- Troubleshooting Checkout — decode what a failing case is telling you
- Checkout in 15 minutes — somewhere to spend this data
This page is also available as Markdown — append .md to its URL — and is indexed in llms.txt.