Open Mercato Payment Collection and Checkout: Operations and Reconciliation Guide

Capability and evidence vocabulary

• available
• configurable
• custom
• integration-required

• latest public release
• current develop
• current first-party documentation
• specification or plan
• external primary requirement
• editorial recommendation

Eleven records, eleven owners

Record system of record, abstract id, amount and currency, state owner, timestamp, update path, retention, join key, exception owner and current evidence.

• 1. customer pay page
• 2. CheckoutLink
• 3. CheckoutTransaction
• 4. GatewayTransaction
• 5. provider PaymentIntent
• 6. SalesPayment and allocation when used
• 7. provider balance transaction
• 8. payout batch
• 9. bank deposit
• 10. invoice or credit memo
• 11. accounting entry

Checkout uses CheckoutTransaction.id as GatewayTransaction.paymentId. Reviewed source contains no automatic SalesPayment creation or allocation. A manual SalesPayment does not prove provider money movement, and a GatewayTransaction does not close an invoice or accounting period.

Capability matrix inventory

Assign one shared capability state plus evidence label, surface, provider dependency, revision, limitation, confidence, owner and acceptance evidence.

• 1. provider registry
• 2. scoped credentials
• 3. provider health
• 4. API-version selection
• 5. embedded presentation
• 6. redirect presentation
• 7. template
• 8. pay link
• 9. authenticated preview
• 10. publish state
• 11. fixed amount
• 12. custom amount
• 13. price list
• 14. customer fields
• 15. legal documents
• 16. branding
• 17. email copy
• 18. password access
• 19. completion limit
• 20. session creation
• 21. capture
• 22. partial capture
• 23. refund
• 24. partial refund
• 25. cancel
• 26. status refresh
• 27. webhook
• 28. status polling
• 29. integration logs
• 30. operator transaction view
• 31. PII view
• 32. export
• 33. events
• 34. notifications
• 35. expiry
• 36. tenant and organization scope
• 37. selected-field encryption
• 38. focused tests

Stripe is the concrete reviewed provider

The adapter contract permits additional providers. A contract, mock, key or example does not prove a maintained, configured or deployment-ready package. The reviewed default application registers Stripe separately. Its runtime descriptor lists card, Apple Pay, Google Pay and Link; the adapter defaults to card when no list is supplied. PayU, Przelewy24, BLIK, PayPal, Adyen, Autopay, bank transfer, and cash are not built-in runtime methods here.

The wildcard currency descriptor is adapter metadata. Test the exact account and matrix for every account country, method, presentment currency, settlement currency, zero-decimal amount, refund and cross-border combination. A Stripe health response proves selected API connectivity and account properties. It does not prove webhooks, methods, SCA, payouts, reconciliation, fraud controls or go-live readiness.

Stripe Payment Element boundary

Payment states and cash movement

• pending
• authorized
• captured
• partially captured
• refunded
• partially refunded
• cancelled
• failed
• expired
• unknown

• processing
• completed
• failed
• cancelled
• expired

Define source, terminal meaning, lost detail and reconciliation before downstream action.

• 1. gateway normalized state
• 2. checkout journey state
• 3. sales-payment state
• 4. provider balance state
• 5. payout state
• 6. bank-receipt state
• 7. accounting and period-close state

Captured records provider-reported capture. It provides no evidence of available balance, settlement, payout, bank receipt, reconciliation, invoicing, revenue recognition, or accounting. Checkout completed records the checkout journey state. It proves no customer identity, proof of delivery, tax receipt, fiscal document, invoice, or chargeback immunity.

Capture, refund and cancel controls

Technical feature grants control system access. They do not grant approval authority or demonstrate segregation of duties. Optional partial amounts and partial states exist. Test provider aggregation, multiple operations, rounding, fees, FX, document effects and reconciliation before acceptance. A local refunded state supplies no evidence that funds reached the customer account.

Webhook trust, duplicate control and recovery

1. 1

   provider endpoint

2. 2

   candidate transaction lookup by provider session id

3. 3

   trusted tenant and organization from stored candidate

4. 4

   scoped credential resolution

5. 5

   provider signature verification

6. 6

   provider event idempotency claim

7. 7

   duplicate skip

8. 8

   queue or direct processing

9. 9

   status mapping and transaction sync

10. 10

    log, failure release and poll recovery

Define expected state, prohibited regression, evidence, retry, poll, correction and owner.

• 1. valid event
• 2. invalid signature
• 3. unknown provider
• 4. unknown transaction
• 5. duplicate event
• 6. delayed event
• 7. missing event
• 8. out-of-order event
• 9. provider retry
• 10. queue failure
• 11. worker retry
• 12. stale local state
• 13. terminal-state conflict
• 14. manual replay or poll recovery

Scope derives from a stored candidate transaction and scoped credentials. Untrusted payload metadata cannot set it. Stripe can retry and duplicate events and does not guarantee ordering. The local claim is released after processing failure. Polling provides recovery infrastructure. It supplies no SLA, scheduler guarantee, or reconciliation engine.

Stripe webhook delivery behavior

Public checkout protections and limits

Record current mechanism, failure mode, deployment dependency and acceptance owner.

• 1. active, draft and inactive link
• 2. nonpayable authenticated preview
• 3. password check
• 4. signed HTTP-only secure same-site cookie
• 5. request host and optional origin
• 6. server-pinned success and cancel origins
• 7. 16 to 128 character Idempotency-Key
• 8. atomic completion-slot reservation
• 9. pricing and currency validation
• 10. customer-field validation
• 11. required legal checkboxes
• 12. configured gateway availability
• 13. status endpoint
• 14. separate PII feature
• 15. selected encrypted fields

View, password and submit rate-limit blocks are fail-open when the limiter service is unavailable. Local idempotency prevents a duplicate scoped CheckoutTransaction row and can return a linked session. Reviewed evidence does not show provider-level exactly-once or concurrent single-flight session creation, capture, or refund. Test same-key concurrency, different keys, timeout, provider-success/local-failure and retry.

A completion reservation controls successful or in-flight uses of one pay link. It does not reserve inventory, a seat, an appointment, capacity, a price or an order. Password access gates a link. It does not prove customer identity, MFA, account authorization, or portal access. A required legal checkbox records configured acceptance data. It provides no evidence of legal validity, identity proof, or compliance assurance.

Sensitive fields and credential environments

Record purpose, reader, encryption evidence, logs, provider processing, retention, export, deletion and incident owner.

• 1. template gateway_settings
• 2. link gateway_settings
• 3. customer_data
• 4. first_name
• 5. last_name
• 6. email
• 7. phone
• 8. accepted_legal_consents
• 9. ip_address
• 10. user agent
• 11. provider and session ids
• 12. client_secret
• 13. gateway_metadata
• 14. webhook_log
• 15. integration log
• 16. sales-payment references

Reviewed default encryption covers checkout gateway_settings; checkout customer_data, first_name, last_name, email, phone, accepted_legal_consents and ip_address; and gateway client_secret, gateway_metadata and webhook_log. It does not cover user agent, provider/session ids, statuses, amounts, or integration logs. Field encryption covers storage for the named fields. It does not settle display access, analytics, exports, provider copies, backups, keys, retention, deletion, privacy rights, incident response or PCI scope. checkout.viewPii and checkout.export remain separate least-privilege surfaces.

Assign operator, approver, test, evidence, failure response and rollback.

• 1. test and live key pairing
• 2. publishable key
• 3. secret key
• 4. webhook secret
• 5. API version
• 6. enabled state
• 7. preset and force behavior
• 8. provider health
• 9. rotation
• 10. revocation
• 11. environment isolation
• 12. log redaction
• 13. backup handling
• 14. incident owner
• 15. production approval
• 16. rollback evidence

Seven-record reconciliation chain

Define join keys, gross and net amount, presentment and settlement currency, status/time basis, owner, frequency, tolerance, expected timing, exception queue, correction, evidence retention and period-close rule.

1. 1

   checkout attempt

2. 2

   gateway and provider payment

3. 3

   sales document and payment allocation when used

4. 4

   provider balance transaction

5. 5

   payout batch

6. 6

   bank deposit

7. 7

   accounting entry

• fees and net or gross
• tax
• partial capture
• partial or multiple refunds
• FX
• rounding
• failed payout
• reserve
• negative balance
• duplicate
• orphan
• late event
• chargeback
• period-close correction

Current GatewayTransaction contains no provider balance transactions, payout batches, fees, reserves, bank deposits, ledger accounts, or accounting postings. The provider, bank and accounting systems remain authoritative for those records. If an integration connects them to GatewayTransaction, test it separately.

Stripe payout reconciliation terms

Disputes need an authoritative case

Not established as a complete workflow by the reviewed checkout and gateway layers.

• 1. dispute case identity
• 2. reason and deadline
• 3. fee
• 4. provisional debit
• 5. evidence pack
• 6. representment
• 7. authoritative won or lost outcome
• 8. sales-document adjustment
• 9. accounting correction
• 10. customer communication

Current Stripe mapping treats charge.dispute.created as failed and charge.dispute.closed as captured. This coarse mapping supplies no dispute outcome. Treat dispute.closed as merchant victory only with provider-authoritative won or lost data and reconciliation.

Stripe dispute lifecycle boundary

Responsibilities and segregation

Assign responsible, accountable, consulted and informed roles plus denied combinations and evidence.

• 1. publish pay link
• 2. edit price and legal text
• 3. manage credentials
• 4. promote test to live
• 5. capture funds
• 6. request refund
• 7. approve refund
• 8. execute refund
• 9. cancel session
• 10. view or export PII
• 11. monitor webhooks
• 12. poll or replay
• 13. support customer
• 14. update sales document
• 15. reconcile payout and bank
• 16. post accounting entry
• 17. respond to dispute
• 18. rotate secrets and approve release

Three synthetic journeys

Load only abstract states, owners, failure branches, reconciliation, evidence and stop conditions.

Poor fit without separately evidenced architecture

• subscription billing: requires a provider, package, custom architecture, specialist authority and competent review.
• marketplaces or split settlement: requires a provider, package, custom architecture, specialist authority and competent review.
• escrow: requires a provider, package, custom architecture, specialist authority and competent review.
• multi-party payouts: requires a provider, package, custom architecture, specialist authority and competent review.
• stored value or wallets: requires a provider, package, custom architecture, specialist authority and competent review.
• offline terminal or POS: requires a provider, package, custom architecture, specialist authority and competent review.
• advanced fraud decisioning: requires a provider, package, custom architecture, specialist authority and competent review.
• high-volume dispute operations: requires a provider, package, custom architecture, specialist authority and competent review.
• regulated payment activity: requires a provider, package, custom architecture, specialist authority and competent review.
• complex tax or fiscalization: requires a provider, package, custom architecture, specialist authority and competent review.
• unsupported local payment methods: requires a provider, package, custom architecture, specialist authority and competent review.

Conditional go-live evidence pack

Name owner, evidence, exception, rollback and a conditional go or no-go decision. This pack supplies no score or certification.

• 1. provider account and mode
• 2. methods and currencies
• 3. credential pairing
• 4. webhook endpoint and secret
• 5. public origin and return URLs
• 6. content security policy
• 7. checkout copy
• 8. legal review
• 9. accessibility
• 10. PII access and export
• 11. roles and segregation
• 12. capture and refund approvals
• 13. customer support
• 14. idempotency and concurrency
• 15. monitoring
• 16. queues
• 17. polling recovery
• 18. reconciliation
• 19. accounting handoff
• 20. dispute response
• 21. incident response
• 22. rollback
• 23. evidence sign-off
• 24. unresolved-exception decision

Acceptance pack

Specify setup, actor, abstract ids, state sequence, expected provider/local/downstream evidence, forbidden result, failure injection, reconciliation, owner and pass criterion.

• 1. route and draft isolation
• 2. fixed amount
• 3. custom amount
• 4. price-list currency
• 5. inactive link
• 6. nonpayable preview
• 7. wrong password
• 8. password session expiry
• 9. invalid origin
• 10. pinned return URL
• 11. missing idempotency key
• 12. same key retry
• 13. same key concurrency
• 14. different keys
• 15. customer double click
• 16. provider success before local failure
• 17. retry after failure
• 18. completion limit
• 19. required legal checkbox
• 20. PII denied
• 21. PII allowed
• 22. export handling
• 23. test and live key mismatch
• 24. provider health failure
• 25. unsupported method
• 26. unsupported currency combination
• 27. zero-decimal amount
• 28. manual capture
• 29. partial capture
• 30. refund
• 31. partial refund
• 32. multiple refund aggregation
• 33. cancel
• 34. invalid operation state
• 35. valid webhook
• 36. invalid signature
• 37. duplicate webhook
• 38. out-of-order webhook
• 39. queue outage
• 40. poll recovery
• 41. captured before settlement confirmation
• 42. payout mismatch
• 43. bank mismatch
• 44. accounting mismatch
• 45. dispute created
• 46. dispute closed without outcome
• 47. no-JavaScript and print
• 48. local worksheet privacy

Stop conditions

• no merchant or payment-operations owner.
• required method or provider is not evidenced.
• test and live controls are mixed.
• no refund approval authority.
• no status-recovery owner.
• no reconciliation keys or exception queue.
• no accounting handoff.
• no dispute authority.
• unreviewed legal or privacy decisions.
• required specialist payment architecture is absent.