Skip to main content

​
Integration boundary

Payment Plugin Architecture Diagram Core mounts the plugins.payment URL configuration at /payment/. Plugin metadata also contributes the Payment Processing settings tab and marks purchases and settings pages as staff-only.

​
Main models

  • PaymentSettings and TaxSettings: legacy-compatible business payment and tax configuration.
  • GatewayAccount: encrypted provider credentials, provider/country data, capabilities, and validation state.
  • PaymentRoute: ordered mapping from a business and currency to an enabled, verified gateway account.
  • Cart and Order: pending line items and immutable completed purchase records.
  • Payment and Refund: transaction and refund records.
  • CheckoutAttempt: server-side amount, currency, customer/guest, provider IDs, policy versions, and checkout lifecycle state.
  • ProviderEvent: webhook payload audit and provider-event deduplication.
  • RefundAttempt: idempotent provider refund lifecycle.
  • MerchantLegalProfile: seller disclosures and versioned terms, privacy, refund, and withdrawal links.
  • ProfilePaymentData and Card: optional saved-payment metadata retained for compatible flows.

​
Provider routing

The routing layer normalizes provider and currency names, validates account capabilities, and refuses unsupported combinations. New integrations should use gateway accounts and payment routes. The legacy one-provider-per-business settings remain as a compatibility path with conservative USD/KRW rules.

​
Important routes

  • /payment/checkout/: checkout for staff, customers, or guests depending on request context.
  • /payment/purchases/: staff purchase history.
  • /payment/settings/: staff provider and payment settings.
  • /payment/payment-refund/: refund requests.
  • /payment/stripe-intent/: Stripe intent creation/confirmation flow.
  • /payment/webhooks/stripe/, /payment/webhooks/paypal/, /payment/webhooks/portone/: signed/asynchronously retried provider events.
  • /payment/ajax/...: cart creation, counts, deletion, and quantity updates.
Provider callbacks validate stored server totals and currency before marking an attempt paid and invoking fulfillment. ProviderEvent prevents the same provider event from being applied more than once.