Eligibility and promise
Identify the seller, customer type, service, accepted currency, provider relationship, tax decision owner, and exact promise made before payment.
Transaction map
Design the record around the payment—not only the button.
A Denmark-facing transaction may show DKK while the contract, provider settlement, invoice, refund, and accounting record follow different paths. The implementation should make those paths explicit before a customer reaches checkout.
State and recovery
Model authentication, duplicate submission, pending status, provider timeout, decline, retry, cancellation, and the message a real user receives.
Evidence and settlement
Connect receipts, invoice data, fulfilment, refunds, chargebacks, settlement reports, and the system of record. A support owner needs a way to explain every state.
Decisions outside engineering
Faith Forge Labs implements an approved commercial model.
The client and qualified advisers determine VAT treatment, invoicing obligations, contract currency, customer classification, and accounting policy. Provider availability and identity-service access are confirmed through client-owned accounts and current terms.
Relevant starting points include the Danish Tax Agency VAT material and Danmarks Nationalbank payment-system information.
Acceptance evidence to request
- A successful DKK journey and an intentional failure journey
- One traceable transaction from interface to settlement record
- Approved receipt, refund, and customer-support wording
- Access rules that keep provider secrets out of source code
- A named owner for tax and provider changes after handoff
Bring a diagram of the current money path.
If there is no diagram, list who charges whom, what is delivered, which provider is used, and where the final record lives.