Testing and go-live

Test keys start with rk_test_; live keys start with rk_live_. Test and live data are separate. A live key can never call sandbox-only routes.

Test the full reminder timeline

Sandbox deliveries cannot reach real customers: e-mail is redirected and SMS/letters are stopped. Advance the organisation clock to trigger the real reminder engine immediately:

curl -X POST https://api.rieckflow.com/v1/test/advance-clock \
  -H "Authorization: Bearer $RIECK_TEST_API_KEY" \
  -H "Idempotency-Key: advance-reminder-day-7" \
  -H "Content-Type: application/json" \
  -d '{ "days": 7 }'

The response lists, in this order, the subscription renewals the new time made due (subscriptions[] — outcome, invoiceId, invoiceNumber, sent) and the reminders triggered (reminders[] — reminder number, fee and whether the invoice is ready for collection). A renewed invoice is dated on its period, never before it. Advance time in deliberate steps and use a new idempotency key for each step; the clock only moves forward, at most 365 days per call.

Sandbox subscriptions renew only through this call and POST /v1/subscriptions/{id}/run, never by the background scheduler — so a sandbox’s next-invoice date does not move until you move the clock.

Test your payment outcomes

A checkout session (POST /v1/checkout-sessions) gives you a reference. In the sandbox you can play the card step for that reference without a browser and choose how the card answers — and Rieck delivers the gateway callback to itself the real way (signed over the raw body, verified, looked up, booked), so your webhook endpoint receives the same event it will in production:

curl -X POST https://api.rieckflow.com/v1/test/gateway-callbacks \
  -H "Authorization: Bearer $RIECK_TEST_API_KEY" \
  -H "Idempotency-Key: play-declined-1" \
  -H "Content-Type: application/json" \
  -d '{ "reference": "FAK-…", "outcome": "declined" }'

outcome	Effect	Your webhook receives
approved (default)	Payment booked on the invoice	payment.received
declined	Rejected by the acquirer; the attempt is recorded	payment.failed
card_expired	Expired card; the attempt is recorded	payment.failed
requires_3ds	Payment waits for a 3-D Secure challenge — not a decline	nothing yet

The outcome lives on this call — never on a card number or an amount ending in a magic digit, so real invoice amounts can never trip a simulated failure. amountOere defaults to the invoice balance and may not exceed it. The fraud guard stays on: repeated failed attempts on one reference return 422 fraud_guard_blocked, which you will want to see before your customers do. A 409 gateway_simulator_unavailable means your sandbox is wired to the gateway’s own test environment; use its test cards on the hosted page there.

Production checklist

• Use a narrowly scoped live key stored only in a server-side secret manager.
• Use a stable idempotency key for every logical write and keep it across retries.
• Verify webhook signatures against the raw body and deduplicate webhook-id.
• Handle 429 and 5xx with backoff; honour Retry-After.
• Persist Rieck ids and your own externalReference together.
• Reconcile critical state with GET after receiving a webhook.
• Test partial payment, credit note, failed delivery and overdue flows.
• Rotate the API key and webhook secret once before launch.
• Log X-Request-Id, endpoint, status and timestamp; never log API keys or webhook secrets.