Payment Information

LandBech Tool accepts three independent payment channels at checkout. Only the channel enabled by the administrator at the moment of the transaction is shown to the technician — the choice is centralized to keep the audit trail clean.

Card numbers, expiration dates and verification codes (CVV/CVC) NEVER touch our servers nor are persisted in our database. The data is captured directly in a PCI-DSS Level 1 certified iframe rendered by the payment gateway. The gateway returns a one-time cryptographic token (nonce) that we use server-side to instruct the charge. The original card number cannot be derived from that token.

• TLS 1.3 mandatory end-to-end transport.
• Idempotency keys per transaction (no duplicate charges on retry).
• PSP-side 3-D Secure 2.0 (Strong Customer Authentication).
• Saved cards on file stored exclusively as gateway tokens — never raw PAN.
• JWT-authenticated Edge Functions for every server-side charge call.

Processing credits are prepaid internal units that cover the operational cost of cloud processing algorithms and distributed compute applied to firmware optimization, signature verification and physical instrumentation procedures. The wallet behaves as a corporate prepaid account: every debit is bound to an atomic SQL RPC with row-level locks, every credit balance is reconciled against the top-up history and the operational ledger is immutable.

• Top-up channels: debit/credit card or audited bank transfer.
• Each debit is dispatched under a single transactional RPC — double-spend is structurally impossible.
• The ledger is exposed to the workshop holder under "Transactions" in the customer account.
• Refunds revert the equivalent credit amount and leave a paired credit/debit trail.

For corporate workshops without a card on file, we accept bank transfer with manual proof upload. The flow is fully auditable end-to-end:

1. The technician requests the order; the system generates a `bank_transfer_orders` record in `pending` state with the official destination account.
2. The customer uploads the deposit voucher (PDF/JPG) to the private storage bucket bound to that order.
3. The super-admin reviews the voucher against the bank statement and, if it matches, approves the order — the system credits the wallet atomically and seals the audit trail.
4. If the deposit cannot be verified, the order is rejected with a documented reason and no credits are granted.

Card refunds are processed against the original transaction (PSP rules). Bank-transfer refunds are coordinated with the customer through the same banking channel. Processing credits debited for a service that was demonstrably not delivered are reverted by the same RPC that consumed them, leaving the ledger balanced.

If a chargeback is opened, we present the manifest, the AWB/TRK, the tokenized payment record and the workflow result log to the issuer or PSP. Disputes lacking evidence on the cardholder side are typically resolved in our favor.

Billing inquiries, voucher resubmission and PSP escalations: soporte@landbechtool.com