The short answer

“The game opens in staging” proves that one happy path worked once in a test environment. Before production, the team must also prove that the candidate and scope are frozen, functional and exception paths have been tested, financial and operational records reconcile, production configuration and access boundaries are controlled, incident ownership is executable, and rollback or shutdown can be carried out safely.

Acceptance should produce evidence and a decision—not simply the phrase “tested.” For every item, record the environment, candidate version, test case, actual result, evidence location, owner and blocker level. An item without evidence remains unverified; a verbal confirmation in a meeting does not convert it into a pass.

Seven evidence areas before production

Area Minimum passing evidence What should block production
1. Scope and candidate Agreed APIs, wallet model, game scope, candidate version, configuration list and exclusions The candidate is still changing, or the tested scope differs from the release scope
2. Functional paths Reviewable results for agreed launch, return, wallet and record-query cases A critical business path fails, or only the front-end display was verified
3. Exception paths Conclusions for timeout, duplicate, disconnection, business failure, partial success and unknown-state cases The final state cannot be established, and recovery depends on blind retries
4. Reconciliation and consistency Stable identifiers correlate requests, transactions, rounds, amounts, currencies and balance movements Records cannot be linked, or discrepancies have no query, handling and closure path
5. Security and environment isolation Staging and production credentials, access, data, logs and configuration boundaries are verified Test credentials are reused, secrets enter code or logs, or production permissions are unclear
6. Ownership and operational readiness Launch decision-maker, engineering response, reconciliation, security and escalation owners are confirmed Only a sales contact exists, or incidents and financial discrepancies have no owner
7. Rollback, shutdown and recovery Triggers, executor, data handling, recovery validation and communication paths are confirmed The integration cannot be stopped safely, or no one reconciles state after rollback

Step 0: freeze scope and the evidence format

Before testing, establish this baseline:

  • release candidate, API-documentation version and configuration version;
  • providers, games, wallet model, currencies, languages and markets intended for launch;
  • explicit exclusions from this release;
  • differences between staging and production;
  • preconditions, inputs, expected business results, actual results and evidence location for each case;
  • defect severity, exception approver and final go/no-go decision owner.

If the release candidate is not the version that was tested, reassess the affected acceptance areas. Do not carry conclusions forward without an impact review.

1. Functional acceptance

Cover the full agreed business chain rather than one game screen:

  • the catalog or target game is identified by the agreed stable ID;
  • session creation, entry, return and expiry behave as agreed;
  • the selected wallet model completes its expected happy path;
  • business results are evaluated under the interface protocol, not inferred only from HTTP status;
  • transaction, round and related records can be queried and tied to test actions;
  • permissions, currencies, languages and devices are tested only for combinations in the frozen baseline.

Write pass conditions as observable results—for example, “the test transaction is returned by the specified business ID and matches the ledger movement”—rather than “wallet works.”

2. Exception acceptance

Choose exception cases from project risk and the actual protocol. They commonly include:

  • request timeout, lost response or broken connection;
  • duplicate submission or duplicate callback;
  • parameter, permission, signature or business-validation failure;
  • partial downstream success where the caller lacks a complete status;
  • lookup, compensation, reconciliation or manual escalation after service recovery;
  • stopping automated action after the agreed retry boundary while retaining evidence.

This checklist requires a tested outcome for exception paths. It does not invent an idempotency key, retry count or backoff value for a project. See Slots API idempotency, retries and reconciliation for the design framework, and use the parties’ formal protocol for implementation details.

3. Record and reconciliation acceptance

Use at least one normal transaction and one exception or unknown-state scenario. Check whether:

  • request, business transaction, round and bet identifiers can be correlated;
  • amount, currency, direction, final state and time interpretation agree;
  • wallet balance or ledger movement matches the transaction record;
  • duplicate events are recognized rather than creating two indistinguishable results;
  • every discrepancy has an owner, handling record, closure condition and audit evidence;
  • the query or export scope supports the agreed operational and finance review.

A passing sample proves only the cases and scope covered. It does not mean future discrepancies are impossible.

4. Security, configuration and environment isolation

Production is not staging configuration copied to a different host. Before release, verify at least that:

  • test and production use separate, controlled credentials, permissions and configuration;
  • secrets do not enter source code, screenshots, ticket bodies or ordinary application logs;
  • production access follows least privilege and has approval, change and revocation records;
  • logs retain enough context for tracing without recording signing secrets, complete credentials or unnecessary sensitive data;
  • test data cannot be mistaken for production transactions, and production data does not enter testing without approval;
  • configuration differences have been reviewed, and production domains, network rules and monitoring targets have passed real project checks;
  • dependencies, clocks, certificates and signing-related settings have named owners.

The UK Gambling Commission’s technical standards include separation of development, test and production systems within their applicable security scope. This is a useful environment-isolation reference, but every market and project still requires its own review. It does not establish complete regulatory or security compliance.

5. Ownership and operational readiness

Turn a contact list into an executable responsibility matrix:

Scenario Responsibility to establish before launch
API or session incident First responder, evidence requirement, engineering escalation and external communication
Financial or record discrepancy Pause condition, reconciliation owner, business decision-maker and closure standard
Catalog or version change Change initiator, impact assessment, notification and regression testing
Credential or security incident Isolation, rotation, investigation, notification and recovery approval
Release and rollback Go/no-go, execution, validation and final record ownership

If response targets, service availability or remedies are launch conditions, place them in the contract or another formally agreed operating document.

6. Rollback, shutdown and recovery

Not every API integration can be reversed with a code rollback. When wallets and transactions are involved, the plan must also cover business events created during the release or rollback window. Confirm:

  • explicit conditions that trigger shutdown or rollback;
  • which entry points can be closed and which in-flight events must still be handled;
  • who executes, approves and verifies the rollback;
  • how service, records and financial state are checked after configuration or version recovery;
  • whether production data must be retained, compensated or manually reconciled;
  • a controlled degradation, pause and communication path when fast rollback is not possible.

Exercise the plan in a safe environment or run a tabletop simulation, and retain the result. This article does not assume that AG provides a particular rollback tool.

The final go/no-go record

Before production, capture one concise decision record:

  • candidate version and configuration;
  • status of all seven evidence areas: verified, conditionally accepted or blocked;
  • unresolved defects and exceptions, including risk, owner and approver;
  • monitoring, escalation, shutdown and recovery responsibilities;
  • separate approval for production access and commercial scope;
  • decision: go, limited-scope go or no-go;
  • decision date and signing roles, without assuming a fixed launch date.

What can currently be evaluated on this site

  • The integration process separates discovery, technical scope, test acceptance and pre-production coordination.
  • The public API reference shows business result codes, request or transaction identifiers, two wallet directions and record queries that can inform test design.
  • A game opening covers only one visible path; it does not prove that wallet, exceptions, records or permissions have passed end-to-end acceptance.
  • Actual runtime behavior and production admission must be based on test evidence from the agreed environment and a signed decision by both parties.

Boundaries to keep in mind

  • This page does not state that AG has supplied staging or production credentials to a specific project.
  • It does not set a fixed test period, release date, retry configuration, performance level, capacity or SLA.
  • Passing staging does not guarantee identical production behavior.
  • It does not establish that a game, version or wallet model suits every platform or market.
  • It does not claim absolute security or replace contract, compliance, security and production change approval.

FAQ

If staging passes, can the team release immediately?

Not automatically. Candidate identity, environment differences, production access, ownership, monitoring, commercial scope and rollback conditions still need review, followed by the agreed go/no-go decision.

Is happy-path testing enough?

No. Timeouts, duplicates, disconnections, business failures and unknown states are common sources of repeated processing and financial discrepancies. Exception cases should enter acceptance according to protocol and risk.

Who signs the production decision?

The project responsibility matrix decides. Engineering, QA, operations or finance, security and the role with production decision authority normally sign their own areas. Sales confirmation does not replace technical or production approval.

Must every project use exactly the same test cases?

The seven evidence areas are a shared skeleton. Specific cases should be tailored to wallet model, scope, target market, current platform and change risk. The tailoring decision should itself be recorded and approved.

To define a project acceptance scope, use the “Contact us” section to provide the wallet model, target games, current platform boundary and expected environments. AG can then collaborate on cases and evidence against the confirmed protocol without promising a launch date or production admission in advance.

Sources and scope

For product scope, see the integration process, Slots API overview and public API reference.

General release methods are informed by Google SRE’s Release Engineering and evolving SRE engagement practices. The market-specific environment-isolation example comes from the UK Gambling Commission’s Remote Gambling and Software Technical Standards: security requirements.

These sources explain general acceptance practices. They do not establish that AG implements every referenced process or that a project complies with a particular market. Production conditions must be agreed by the responsible engineering, QA, operations or finance, security, commercial and compliance roles.

Need to turn this guidance into a project plan?

This article supports project evaluation and does not replace technical, contractual, certification or local-law confirmation.

Contact us