Configure payments3 min read

Recover pending payments and handle extra prints

If payment or printing is interrupted, check the same transaction and job first. Retrying without checking can create duplicate payments or prints.

Version reference: Android 3.0.3 · iOS/iPadOS 1.2.1

Follow the section for your platform. Screenshots show native UI with demo data; menus depend on version, plan and device. Test-build features may not yet be in the public release.

Content reviewed: 2026-10-18

Before you begin

Record the time, device, event and transaction reference if available. Do not ask the guest to pay again before checking status.

Set up booth payments — Workflow diagram. Optional steps depend on event configuration.

Android steps

1On the payment screen, use the available status check and wait for the server result. If reopening the app, follow the offered session recovery.
2After acceptance, check session access and the print allowance. Initial prints, extra prints and reprints follow device policy.
3For operator actions requesting an Admin PIN, use the PIN set by the owner. Do not share it with guests or print it in instructions.
4If printing stops, inspect the queue and physical output before resending from Result/History.

Android Result. Native UI on a physical Android tablet with demo data.

iPhone and iPad steps

1Let the payment-status check finish. When connectivity returns, continue the same transaction/session through the offered recovery.
2Check the session result and print allowance. Use the offered extra-print option when the allowance is exhausted instead of unnecessarily creating a new session.
3For uncertain print status, inspect the printer and queue first. If it still fails, keep the transaction reference and result files for support.

iPad Result. Native SwiftUI UI on iPad Simulator with demo data.

Check the result

Operator check

The transaction status is known, the paid session continues under its entitlement, and no duplicate print job is sent without checking.

If something goes wrong

Symptom	Next step
Bank app shows success but the booth has not continued	Check the same transaction and connectivity; keep its reference and time. Do not promise an automatic refund based only on a screen status.
Admin PIN is rejected	Use the owner PIN management/reset flow. Do not disable payment restrictions to bypass verification.

Android steps

1On the payment screen, use the available status check and wait for the server result. If reopening the app, follow the offered session recovery.

2After acceptance, check session access and the print allowance. Initial prints, extra prints and reprints follow device policy.

3For operator actions requesting an Admin PIN, use the PIN set by the owner. Do not share it with guests or print it in instructions.

4If printing stops, inspect the queue and physical output before resending from Result/History.

Android Result. Native UI on a physical Android tablet with demo data.

iPhone and iPad steps

1Let the payment-status check finish. When connectivity returns, continue the same transaction/session through the offered recovery.

2Check the session result and print allowance. Use the offered extra-print option when the allowance is exhausted instead of unnecessarily creating a new session.

3For uncertain print status, inspect the printer and queue first. If it still fails, keep the transaction reference and result files for support.

iPad Result. Native SwiftUI UI on iPad Simulator with demo data.

If something goes wrong

Symptom	Next step
Bank app shows success but the booth has not continued	Check the same transaction and connectivity; keep its reference and time. Do not promise an automatic refund based only on a screen status.
Admin PIN is rejected	Use the owner PIN management/reset flow. Do not disable payment restrictions to bypass verification.