Test mode (sandbox)

In test mode you can try Rechnungskit without risk: documents go through the same pipeline as real invoices, but they count nowhere and never leave the system. This page shows what happens to your real data, how a test invoice comes about, what you pay test payments with and what happens at go-live.

Connecting real data: what happens and what doesn't

You can connect your real shop and your real payment providers while your current system keeps running. Rechnungskit reads orders and payments and turns them into TEST documents that never leave Rechnungskit. It changes nothing about your orders, sends no invoices, passes nothing to your tax advisor and charges you nothing for test documents.

Real connections in test mode

In test mode, no document leaves Rechnungskit

What happensreading along

Readorders, payments, refunds, payouts

Storein Rechnungskit, marked as test data

Webhookonce when you connect, so events arrive

VAT IDreal check with the BZSt

ResultTEST documents with PDF, only in Rechnungskit

What never happensin test mode

Your shopno change to orders, payments, customer data

Moneyno payment, refund or direct debit on its own, no checkout or subscription charges with live credentials

Invoice emailto your customers strictly blocked

Tax advisorDATEV export only as a test export (TEST_ in the file name), cannot be locked, no ZM

Costtest documents are not billed

Double invoicesyour old system stays in charge

What Rechnungskit does in test mode

• Read: Rechnungskit pulls orders, payments, refunds and payouts from your shop and payment provider and stores them marked as test data.
• Set up a webhook: when you connect, Rechnungskit creates a webhook at Stripe, PayPal, Unzer, the Shopify app and WooCommerce, so new events arrive right away. If you disconnect Shopify or WooCommerce, Rechnungskit removes its webhooks there again.
• Create TEST documents: with PDF and EN 16931 validation, visible only in Rechnungskit.
• Check VAT IDs: if a business customer has a VAT ID (USt-IdNr.), Rechnungskit checks it for real with the BZSt (German Federal Central Tax Office), in test mode too. Your own VAT ID and the customer's VAT ID, company name and address go to the BZSt for this.

What never happens in test mode

• No changes in your shop: Rechnungskit changes no orders, payments or customer data in your shop or at your payment provider.
• No money on its own: Rechnungskit triggers no payments, refunds or direct debits. In test mode, the checkout and subscriptions do not charge with live credentials.
• No invoice emails: invoices and payment reminders to your customers are strictly blocked.
• Nothing real for your tax advisor: Rechnungskit sends them nothing. In test mode a DATEV export is always a test export: marked (TEST_ in the file name), it cannot be locked and is deleted at go-live. The ZM (EC sales list) stays empty.
• No cost: test documents do not count toward your billing.
• No double invoices: until go-live, only your current system issues invoices.

Checkout and subscriptions in test mode

Add your provider's test credentials under Settings → Connections. Below the Mollie, Stripe, PayPal and Unzer cards, open "Test credentials (for checkout and subscriptions in test mode)". Checkout and subscriptions use them automatically in test mode. Your live connection stays next to them, so your real payments keep coming in as test documents.

A live key is rejected in this field. "Remove" deletes the test credentials again; your live connection is not affected.

You don't need a live connection to test. If you connected a provider with test credentials only, you can still select it for checkout or subscriptions in test mode. The card then shows the note "Connected with test credentials only". Before go-live, connect the live credentials. If they are missing, the go-live check warns you, and after go-live payment with this provider is unavailable until you have connected the live credentials. A live account never falls back to the test credentials.

Without test credentials, Rechnungskit blocks the payment in test mode as soon as a provider with live credentials is selected for the checkout or for subscriptions. Otherwise your customer would pay real money and only get a test document.

• Checkout and shop: buyers see "Test mode: payment not possible. The seller is currently testing this checkout." Invoice purchase and prepayment stay available, since no money runs through a provider there.
• Subscriptions: new subscriptions don't start. Due follow-up payments wait, with no failed attempt, no dunning step and no email.
• Stripe bank transfer via the API: for orders with paymentGateway stripe_transfer, Rechnungskit creates no payment request in Stripe. The order waits, and a task tells you why. With Stripe test credentials, Rechnungskit creates the customer and the payment request in your Stripe test account.

You pay with your provider's test data (see What do you pay a test payment with?). Otherwise a test purchase works like a real one, with these differences:

• Emails to buyers go only to your own address (the contact email from your settings, otherwise the owner's), with "[TEST]" in front of the subject. That applies to all subscription notices, such as subscription active, failed payment, cancellation or withdrawal. The invoice email stays blocked for test documents.
• Integrations and webhooks run as in live operation, such as access in Ghost or Memberspot and your own webhooks. The webhook payload then carries "test": true.
• Ad tracking: conversion events to Meta are not sent for test purchases and test subscriptions. The purchase pixel of Meta, Google and TikTok on the thank-you page stays off too. That keeps test purchases out of your ad reports.
• Payments through test credentials are always test payments. They never turn into a real document, not even after go-live.

At go-live, the test credentials are switched off and running test subscriptions end immediately, with no email to buyers and no charge. Access that test purchases and test subscriptions unlocked in Ghost or Memberspot is revoked at the same time, the same way as after a full refund. Checkout links, the shop and subscription plans stay and run through your live connection from then on.

Common worries

How a test invoice comes about

An invoice comes about in Rechnungskit in two ways, in test mode just as in live operation:

• Automatically from an order and a payment: an order comes from your shop or via API, the matching payment from your connected payment provider. As soon as both are there and match, Rechnungskit creates the document itself.
• From an order you create yourself: under Orders → "Create order". With the payment method invoice, the invoice comes about in the same step; for goods that haven't shipped yet, only with "Mark as shipped". With prepayment it comes about as soon as you confirm "Payment received". Details are in Manual orders and invoices.

In test mode both ways produce a TEST document with its own TEST number. No email goes out to your customers.

Automatic route · three steps

Test invoice from an order and a payment

1. Shop or APIOrdertest order in the shop or POST /v1/orders, shows up under "Orders"
2. Payment providerPaymentmatched by order number or transaction ID (paymentRef)
3. RechnungskitTest documentTEST number range, with PDF and EN 16931 validation

This is how you get a test invoice the automatic way:

1. Connect a data source and create an order. Either connect a shop (Shopify, WooCommerce, Shopware) and place a test order there. Or, as a SaaS or your own application, report an order via API (POST /v1/orders with your API key). The order then shows up under "Orders".
2. Connect a payment provider and make a payment for the order (Stripe, Mollie, PayPal, Unzer, GoCardless, Klarna). The easiest way is to connect your live credentials, as described below under Test mode and payment providers. Your real payments then run through as test documents. For checkout and subscriptions you also add test credentials, and then you pay with the provider's test data. Matching works through the order number or the transaction ID (paymentRef).
3. Rechnungskit creates the test document. If the payment matches the order, the test document comes about automatically (TEST number range), including the PDF and EN 16931 validation. If a payment arrives without a matching order, Rechnungskit reports "Payment without an order" in the tasks under /payments. In that case the order is still missing.

The quickest way to see a test invoice is an order you create yourself: payment method invoice and a service or product that isn't shipped, and the TEST document comes about right away. You need an IBAN in your settings for this. If you just want to see the layout, use the live preview of the invoice template under Settings → Invoice template. It shows a sample invoice with your logo and your texts, without creating a document.

What do you pay a test payment with?

With your payment provider's test data, not with data from Rechnungskit. We do not process payments: the money runs through your own account with the provider, and its sandbox supplies the test cards and test IBANs. As long as a test key is stored there, no real money moves.

Which payment methods appear

Your provider account decides which payment methods appear in the checkout. For Mollie and Unzer, Rechnungskit reads the enabled methods and shows them under Settings → Connections. "Refresh" reads them again. If you enable another payment method with the provider, it then shows up in the checkout too.

The Rechnungskit Checkout works with Mollie, Stripe, PayPal and Unzer. For subscriptions it is Mollie and Stripe, because recurring collection needs a mandate.

What applies in test mode

Same account · two states

Test mode and live operation compared

Test modeSandbox

NumberTEST-2026-0001

In the document"Testbeleg, keine Rechnung, kein Steuerausweis"

Costnot metered

Invoice emailstrictly blocked

DATEV, OSS, ZMno real export, OSS only as a preview

Archivecan be reset at any time

After go-liveLive

Numberyour format, e.g. RE-2026-0001

In the documentreal invoice with VAT statement

Costcounts toward your billing

Invoice emailautomatic, can be turned off

DATEV, OSS, ZMincluded

Numberingno gaps, can no longer be changed

• Separate number range: test documents are called TEST-2026-0001 and so on, and your real number range stays untouched.
• Notice in the document: every test document carries a clear notice in the document itself ("Testbeleg, keine Rechnung, kein Steuerausweis": test document, not an invoice, no VAT statement).
• Not metered: test documents cost nothing and do not count toward your billing.
• No invoice emails: invoices and payment reminders to your customers are strictly blocked in test mode. The block is tied to the test document itself, so it still applies after go-live.
• No effect on reports: test documents appear neither in real DATEV exports nor in the ZM (the EC sales list). In the OSS overview they only show as a preview while the project is in test mode, and no longer after go-live. For a trial import, you (or your tax advisor) can create a marked test export. It has TEST_ in the file name, cannot be locked and is deleted at go-live or when you reset the sandbox.
• Archive: the archive is not write-protected in test mode, and you can reset test data at any time.

After go-live it is the other way round: real invoices with a VAT statement come about in your number format. They count toward your billing, go to your customers by email by default (you can turn this off) and end up in DATEV, OSS and ZM.

Enabling and resetting test mode

Every new account starts in test mode. For a project without real documents, you switch it on under Settings, in the project management ("Test mode (sandbox)").

"Reset sandbox" deletes the test PDFs from the archive, the test DATEV exports and the test payout documents, and starts the 90-day test phase over. Orders, payments and customer data stay stored. The project, connections and settings stay the same, and real documents only come about with go-live.

API keys in test mode

The API integration has a single key type (prefix rk_key_). In test mode it creates only test documents. So you can run through your whole integration, including EN 16931 validation and PDF creation, before any real documents are created.

At go-live the same key stays valid and creates real documents from then on. You do not need to swap the key or touch your integration. Older keys with the rk_test_ prefix keep working unchanged. API details are in Connect your own application via API.

Test mode and payment providers

Important for all payment providers (Stripe, Mollie, PayPal, Unzer, GoCardless, Klarna): connect your live credentials, not the provider's sandbox or test credentials.

Credentials at the payment provider

Which credentials you connect in test mode

Live credentials plus Rechnungskit test modeYour real payments run through as TEST documents, no invoice is sent or exported

Recommended

Test credentials added on topsk_test_, test_, PayPal sandbox or s-priv-: in the separate "Test credentials" field below the live connection, only for checkout and subscriptions in test mode

test payments only

Test keys as the main connection at go-liveblock go-live, so that test payments never turn into real documents. The additional test credentials don't block; they are switched off.

Blocked

Why? A provider sandbox is an empty parallel world where your real payments never appear, so no data reaches Rechnungskit either.

So the risk-free way to test is Rechnungskit's test mode with real credentials. Rechnungskit does not trigger payments on its own, and in test mode the checkout and subscriptions don't charge with live credentials. What else happens and what doesn't is explained above under Connecting real data. How you test the checkout and subscriptions is under Checkout and subscriptions in test mode.

Test credentials (for example Stripe sk_test_, Mollie test_, Unzer s-priv-) are recognized by their prefix. As the main connection they only deliver test payments from the provider's sandbox; for live operation, replace them with your live credentials under Connections. For checkout and subscriptions they belong in the separate "Test credentials" field below the live connection, see Checkout and subscriptions in test mode.

Testing alongside your old system

Because Rechnungskit changes nothing about orders, payments or customer data in test mode and sends no invoices, your current system keeps running as usual. No duplicate invoices come about. This lets you see with real numbers how matching, the fee split and the DATEV preview would look for you.

Running in parallel

Your old system invoices, Rechnungskit does a trial run

Your shop and payment provider

Real ordersstay unchanged

Real paymentsRechnungskit triggers none

Rechnungskit in test mode

1. Reads alongorders, payments, refunds
2. Matchesas it will in live operation
3. Creates TEST documentsno VAT statement, no sending

Invoices to customers

Until go-liveonly from your current system

From the Belegstartonly from Rechnungskit

Only when everything fits do you go live with a Belegstart date (the cut-over date from which Rechnungskit issues your documents). From then on, only Rechnungskit creates the documents. Orders and payments from before the Belegstart count as historic, and Rechnungskit never invoices them on its own; your current system keeps handling those.

Go-live: what you decide

At go-live (under "Go live"), Rechnungskit checks a few points and asks for three things that get decided right then.

Going live · in place

From test mode to live operation

1. CheckPayment method and keysno go-live without a payment method for the fees or with test keys
2. DecideNumber range and sendingformat, first invoice number, email sending on or off
3. BelegstartNow or scheduledto the minute, from then on only Rechnungskit creates documents
4. After thatTest data disappearshidden, test PDFs deleted, confirmation by email

Payment method for your fees

Before you go live, a payment method for your Rechnungskit fees must be on file so the first real invoice can be billed. There are two ways:

• SEPA direct debit: you set it up right in the go-live window.
• Shopify bill: automatic, if you came through the Shopify App Store.

Without a payment method, go-live is blocked.

Invoice number range and next invoice number

You set your number format: JJJJ stands for the year, #### for the sequential number. RE-JJJJ-#### gives RE-2026-0001, for example. You also pick the number the first real invoice starts with.

This lets you continue your previous numbering seamlessly (from 1043, say) or start at 1. From the first real document on, the numbering has no gaps and can no longer be changed.

Send invoices automatically by email

This is on by default. As soon as you are live, Rechnungskit sends every finished invoice to your customers automatically, in your name and with your template. You can untick this in the go-live window and change it at any time under Settings → Email delivery.

Test keys and Belegstart

An active connection with a test key also blocks go-live, so that test payments never turn into real documents. The additional test credentials for checkout and subscriptions don't count; go-live switches them off itself. After that you choose the Belegstart date, immediately or scheduled to the minute. From that moment on, only Rechnungskit creates the documents.

If test subscriptions are still running, the checklist shows "N test subscriptions will end".

What happens to your test data at go-live

Go-live switches your account to live operation in place: the same environment, the same connections, the same settings. Your test data is handled like this:

• Test documents, test orders and test payments are hidden immediately from all lists, reports and exports (DATEV, OSS, ZM). They never count toward your real numbers.
• The archived test PDFs are deleted from storage.
• The test number range (TEST-…) is retired. Your first real invoice uses the number range you set at go-live.
• Test subscriptions end immediately. Buyers get no email, and nothing is charged.
• Access from test purchases and test subscriptions in Ghost or Memberspot is revoked, the same way as after a full refund. The go-live check shows beforehand whether there is any. If you switched off automatic revocation in the integration, that access stays.
• The test credentials for checkout and subscriptions are switched off. Checkout links, the shop and subscription plans run through your live connection from then on. If a provider connected with test credentials only was selected for checkout or subscriptions, payment there is unavailable until you connect its live credentials.
• Your connections and settings stay as they are, and you do not need to reconnect anything.

Scheduling go-live for later

If you schedule go-live for a future time, everything stays in test mode until then. No test phase or expiry notice is sent beforehand.

You can change the number range and email sending until then: adjust them and click "Save changes", and the scheduled time stays. As soon as you are live, owners and admins get an email confirmation with the Belegstart, the first invoice number and the sending setting.

At the scheduled time, Rechnungskit checks the test keys once more. If an active connection runs on a test key at that point, the switch does not happen. Your account stays in test mode, the schedule is cleared, and owners and admins get an email explaining why.

Limits

• Test mode is meant for trying out features, not for load tests (fair use).
• At go-live your account goes live in place: connections and settings remain, and test data is hidden and removed from the archive. You do not set anything up again.