Skip to content
ReanOrt
ធនធាន • ស្ថាបត្យកម្ម • បានអាប់ដេត: Feb 2026

ភ្ជាប់បង់ប្រាក់, SMS និងគណនេយ្យ៖ ស្ថាបត្យកម្មស្អាត

វិធីអនុវត្ត ដើម្បីភ្ជាប់សេវាកម្មខាងក្រៅ ដោយមិនធ្វើឲ្យកូដរបស់អ្នករញ៉េរញ៉ៃ—ប្រើស្រទាប់ស្អាត, idempotency, queue និងកំណត់ត្រាដែលអាច audit បាន។

Gateway បង់ប្រាក់ ផ្ញើ SMS Sync គណនេយ្យ Queue + Webhook

សង្ខេបសម្រាប់អ្នកដឹកនាំ

ការភ្ជាប់ស្អាតបំផុត គឺពេលច្បាប់អាជីវកម្មស្នូល មិនអាស្រ័យលើ vendor SDK។ អ្នកបំបែក vendor ទុកក្រោយ adapter, ដំណើរការសកម្មភាពជាមួយ queue, និងរក្សាទុកការទំនាក់ទំនងខាងក្រៅជាកំណត់ត្រាអាច audit បាន។

គោលដៅ
ប្ដូរ vendor បាន
ប្ដូរ gateway/SMS ងាយ។
គោលដៅ
ប្រតិបត្តិការមានស្ថិរភាព
Retry, idempotency, queue។
គោលដៅ
អាច audit បាន
កត់ត្រាសកម្មភាពទាំងអស់។

វិធីសាស្ត្រ Clean Architecture

គិតជាស្រទាប់។ ស្រទាប់ “Domain” និង “Application” គួរតែមានស្ថិរភាព។ Gateway បង់ប្រាក់, SMS provider និងប្រព័ន្ធគណនេយ្យ ស្ថិតនៅស្រទាប់ Infrastructure (adapter)។

Domain (ច្បាប់អាជីវកម្ម)
វិក្កយបត្រ បង់ប្រាក់ បញ្ជីគណនី ការជូនដំណឹង—តែ logic មិនបញ្ចូល vendor code។
Application (Use Case)
រៀបចំជំហាន៖ បង់ប្រាក់ បញ្ជាក់ បញ្ចូលគណនេយ្យ ជូនដំណឹងអតិថិជន។
Infrastructure (Adapter)
Gateway បង់ប្រាក់, SMS provider, Accounting API—អាចប្ដូរបាន។
Delivery (UI/API)
Controller, webhook, queue—តែ transport មិនមែន business logic។
ច្បាប់ #1

Controller មិនគួរហៅ payment SDK ដោយផ្ទាល់ទេ។ Controller ហៅ use-case service; use-case ហៅ interface; adapter អនុវត្ត interface នោះ។

លំហូរភ្ជាប់ដែលអាចប្រើក្នុងផលិតកម្ម

បង់ប្រាក់ និង SMS ជា “side effects”។ គួររក្សាទុកជាជំហាន asynchronous តាម queue បើអាច។ Accounting sync គួរតែមានភាពជាប់លាប់ និងអាច audit បាន—not “best effort”។

1
Create invoice
Generate invoice number, amount, customer, and due date. Status: Pending.
2
Initiate payment
Create payment intent with idempotency key. Store request/response.
3
Webhook confirms payment
Verify signature, ensure idempotency, update payment status.
4
Post to accounting (queued)
Create journal entries / receipts via adapter. Retry on failure.
5
Send receipt SMS (queued)
Send SMS using templated message; log delivery status.
ហេតុអ្វីវាដំណើរការ
  • Webhook ត្រូវបាន verify និងមាន idempotency (retry បានដោយសុវត្ថិភាព)។
  • Accounting និង SMS ដំណើរការតាម queue (UI មិនយឺត)។
  • រាល់ការហៅខាងក្រៅត្រូវបានកត់ត្រា (audit trail)។

Idempotency៖ ឧបករណ៍លេខ១សម្រាប់ភាពជឿជាក់

ក្នុង payment និង webhook ព្រឹត្តិការណ៍អាចកើតឡើងម្តងហើយម្តងទៀត។ Idempotency ធានាថា មិនស្ទួនបង់ប្រាក់ ឬស្ទួនបញ្ចូលគណនេយ្យ។

កន្លែងដែលត្រូវប្រើ
  • បង្កើត payment intent
  • ដំណើរការ webhook
  • បញ្ចូលគណនេយ្យ
  • ផ្ញើ SMS (ជៀសវាងស្ទួន)
របៀបអនុវត្ត
  • ប្រើ key = invoice_id + action
  • រក្សាទុក event ដែលបានដំណើរការ
  • បើដំណើរការរួច—return ទៅវិញ
  • ធ្វើ job អាច retry បាន

អ្វីដែលគួរជៀសវាង

Calling vendor SDK in Controllers
Hard to test; UI failures break payments; mixing transport and business rules.
Syncing accounting inside the payment callback
If accounting is slow/unavailable, you break payments and user experience.
No audit trail for external requests
You can’t answer: “What happened?”, “Who retried?”, “Which payload was sent?”
No idempotency on webhooks
Duplicate webhooks can double-post receipts or double-send SMS.

ត្រូវរក្សាទុកអ្វីខ្លះសម្រាប់ Audit និង Debug

អ្នកមិនចាំបាច់រក្សាទុកទាំងអស់ជារហូតទេ ប៉ុន្តែត្រូវមានគ្រប់គ្រាន់ ដើម្បីពន្យល់ side effect ខាងក្រៅទាំងអស់។

កំណត់ត្រា វាល ហេតុផល
payment_attempts invoice_id, idempotency_key, request, response, status តាមដានជីវិត payment។
webhook_events provider, event_id, payload_hash, received_at, processed_at Idempotency និង replay។
accounting_posts invoice_id, journal_ref, request, response, status, retries Audit និង reconciliation។
sms_messages to, template, payload, provider_msg_id, status តាមដានការផ្ញើ។

ត្រូវការជំនួយអនុវត្ត?

ReanOrt អាចរចនាស្ថាបត្យកម្មភ្ជាប់ អនុវត្ត webhook និង queue ដែលជឿជាក់ និងដឹកជញ្ជូនលំហូរហិរញ្ញវត្ថុដែលអាច audit បាន។

ស្នើសុំសាកល្បង ស្នើសុំតម្លៃ បញ្ចូលប្រព័ន្ធពិសេស →