> For the complete documentation index, see [llms.txt](https://docs.coda.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coda.co/coda-webstore/test-transactions-in-webstore.md).

# Test transactions in webstore

You can run real test transactions against your sandbox store, end to end, without spending real money and without any integration work on your side.

## What this gives you

Your sandbox store connects to the **Codapay sandbox environment** automatically. There's nothing for your engineering team to build and nothing to configure to get a working test transaction — it works as soon as your sandbox store exists.

This is available in **every country where the Codapay sandbox environment is supported**, so you can validate market by market rather than testing one geography and assuming the others behave identically.

What you can verify:

* That a player can complete a purchase on your store, from catalogue to confirmation
* That your player ID validation behaves the way you expect
* That fulfilment reaches the right account
* That the login experience works, if your store uses accounts
* That any layout or styling change you've made still works when a real transaction runs through it

## Choosing what your sandbox connects to

You control which of your own environments your sandbox store talks to for **validation** and **top-up**. There are three options:

| Option             | What it does                         | When to use it                                                                                               |
| ------------------ | ------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
| **Dummy endpoint** | Always returns a successful response | Testing the store experience itself — layout, styling, checkout flow — without involving your backend at all |
| **Staging**        | Points at your staging environment   | Testing your own validation and fulfilment logic before it reaches production                                |
| **Production**     | Points at your live environment      | Verifying against real player accounts and real fulfilment behaviour                                         |

Different tests need different levels of realism, and you can switch between these as needed rather than being locked into one mode.

## Testing the login experience

Accounts are available in the sandbox environment too. If your store uses account login, you can point it at your sandbox accounts setup and simulate the full login journey — not just the payment leg.

This means the thing you're testing is your actual store experience end to end, rather than a payment flow in isolation.

## Why this replaced testing in production

Previously, seeing a real transaction run through a store meant doing it in production behind feature flags — which was slower, riskier, and dependent on Coda to schedule and run for you. Sandbox transactions remove that dependency entirely. You can test your own store, in your own markets, whenever you want to.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.coda.co/coda-webstore/test-transactions-in-webstore.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.