Płatności online w Open Mercato: checkout, operacje i uzgodnienie

Słownik możliwości i dowodów

• available
• configurable
• custom
• integration-required

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

• autoryzacja
• przechwycenie środków
• anulowanie
• zwrot
• zwrot częściowy
• spór lub chargeback
• saldo dostawcy
• wypłata środków
• wpływ bankowy
• uzgodnienie
• księgowanie

Jedenaście rekordów, jedenaście odpowiedzialności

Zapisz system of record, abstrakcyjny id, kwotę i walutę, właściciela stanu, timestamp, update path, retencję, join key, właściciela wyjątku i bieżący dowód.

• 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 używa CheckoutTransaction.id jako GatewayTransaction.paymentId. Sprawdzony kod nie potwierdza automatycznego tworzenia ani alokacji SalesPayment. Ręczny SalesPayment nie dowodzi ruchu środków u dostawcy, a GatewayTransaction nie zamyka faktury ani okresu księgowego.

Inwentarz macierzy możliwości

Przypisz jeden wspólny capability state oraz evidence label, powierzchnię, zależność od dostawcy, rewizję, ograniczenie, confidence, właściciela i 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 jest konkretnym sprawdzonym dostawcą

Kontrakt adaptera pozwala dodać innych dostawców. Contract, mock, key ani example nie dowodzi utrzymywanego, skonfigurowanego i gotowego do wdrożenia pakietu. Sprawdzona aplikacja domyślna rejestruje osobno Stripe. Runtime descriptor wymienia card, Apple Pay, Google Pay i Link; bez listy adapter używa card. PayU, Przelewy24, BLIK, PayPal, Adyen, Autopay, bank transfer i cash nie są tu potwierdzonymi metodami built-in.

Wildcard currency w descriptorze to metadata adaptera. Przetestuj dokładne konto i macierz dla każdego kraju konta, metody, waluty prezentacji, waluty settlement, kwoty zero-decimal, refundu i kombinacji cross-border. Odpowiedź Stripe health dowodzi wybranej łączności API i właściwości konta. Nie potwierdza webhooków, metod, SCA, payout, reconciliation, kontroli fraud ani gotowości go-live.

Granica Stripe Payment Element

Stany płatności i przepływ gotówki

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

• processing
• completed
• failed
• cancelled
• expired

Zdefiniuj źródło, znaczenie terminalne, utracony detal i reconciliation przed działaniem downstream.

• 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 rejestruje capture zgłoszone przez dostawcę. Nie potwierdza available balance, settlement, wypłaty, wpływu bankowego, uzgodnienia, fakturowania, rozpoznania przychodu ani księgowania. Checkout completed rejestruje stan ścieżki checkout. Nie potwierdza tożsamości klienta, proof of delivery, tax receipt, dokumentu fiskalnego, faktury ani odporności na chargeback.

Kontrole capture, refund i cancel

Feature grants techniczne kontrolują dostęp do systemu. Nie przyznają uprawnień do zatwierdzania ani nie potwierdzają rozdziału obowiązków. Istnieją optional partial amounts i partial states. Przed odbiorem przetestuj agregację dostawcy, wiele operacji, rounding, fees, FX, skutki dokumentowe i reconciliation. Lokalny refunded state nie potwierdza wpływu środków na konto klienta.

Zaufanie webhooka, duplikaty i 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

Zdefiniuj oczekiwany stan, zabronioną regresję, dowód, retry, poll, korektę i właściciela.

• 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 pochodzi ze stored candidate transaction i scoped credentials. Niezaufane metadata payloadu nie mogą go ustalać. Stripe może ponawiać i duplikować events oraz nie gwarantuje kolejności. Lokalny claim jest zwalniany po failure processing. Polling zapewnia infrastrukturę recovery. Nie zapewnia SLA, gwarancji schedulera ani reconciliation engine.

Zachowanie dostarczania webhooków Stripe

Ochrona publicznego checkout i ograniczenia

Zapisz mechanizm, failure mode, zależność wdrożenia i właściciela odbioru.

• 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

Bloki rate-limit dla view, password i submit są fail-open, gdy limiter service jest unavailable. Lokalna idempotency zapobiega duplicate scoped CheckoutTransaction i może zwrócić linked session. Sprawdzone dowody nie potwierdzają provider-level exactly-once ani concurrent single-flight dla session creation, capture lub refund. Testuj same-key concurrency, different keys, timeout, provider-success/local-failure i retry.

Completion reservation kontroluje udane lub in-flight użycia jednego pay link. Nie rezerwuje inventory, seat, appointment, capacity, price ani order. Password access chroni link. Nie potwierdza tożsamości klienta, MFA, account authorization ani portal access. Required legal checkbox zapisuje configured acceptance data. Nie potwierdza legal validity, identity proof ani compliance assurance.

Pola wrażliwe i środowiska poświadczeń

Zapisz cel, reader, dowód szyfrowania, logi, processing providera, retencję, export, deletion i 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

Sprawdzone default encryption obejmuje checkout gateway_settings; checkout customer_data, first_name, last_name, email, phone, accepted_legal_consents i ip_address; oraz gateway client_secret, gateway_metadata i webhook_log. Nie obejmuje user agent, provider/session ids, statusów, kwot ani integration logs. Field encryption obejmuje przechowywanie wskazanych pól. Nie rozstrzyga display access, analytics, export, provider copies, backups, keys, retention, deletion, praw prywatności, incident response ani PCI scope. checkout.viewPii i checkout.export pozostają osobnymi least-privilege surfaces.

Przypisz operatora, approvera, test, dowód, reakcję na awarię i 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

Siedmiorekordowy łańcuch uzgodnienia

Zdefiniuj join keys, gross i net amount, presentment i settlement currency, podstawę statusu/czasu, ownera, częstotliwość, tolerance, expected timing, exception queue, correction, retencję dowodów i 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

Bieżący GatewayTransaction nie zawiera provider balance transactions, payout batches, fees, reserves, bank deposits, ledger accounts ani accounting postings. Systemy providera, banku i księgowości pozostają autorytatywne dla tych rekordów. Jeśli integracja łączy je z GatewayTransaction, przetestuj ją osobno.

Terminy payout reconciliation Stripe

Spory wymagają autorytatywnej sprawy

Niepotwierdzone jako kompletny workflow w sprawdzonych warstwach checkout i gateway.

• 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

Bieżące mapowanie Stripe traktuje charge.dispute.created jako failed, a charge.dispute.closed jako captured. To coarse mapping nie podaje wyniku sporu. Traktuj dispute.closed jako zwycięstwo merchant wyłącznie na podstawie provider-authoritative danych won lub lost i reconciliation.

Granica cyklu sporu Stripe

Odpowiedzialności i segregation

Przypisz role responsible, accountable, consulted i informed oraz zabronione kombinacje i dowód.

• 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

Trzy syntetyczne ścieżki

Wczytaj tylko abstrakcyjne stany, właścicieli, failure branches, reconciliation, dowody i stop conditions.

Słabe dopasowanie bez osobno potwierdzonej architektury

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

Warunkowy pakiet dowodów go-live

Nazwij ownera, dowód, wyjątek, rollback i warunkową decyzję go lub no-go. Ten pakiet nie daje wyniku ani certyfikacji.

• 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

Pakiet odbioru

Podaj setup, actor, abstrakcyjne ids, state sequence, oczekiwany dowód provider/local/downstream, forbidden result, failure injection, reconciliation, ownera i 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

Warunki stop

• 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.