Order Payment

First-Pass Node Dossier

This page is an evidence-backed node dossier generated from the domain hierarchy and node questionnaire.

What It Is

OrderPayment is the transactional record that stores how much was charged, captured, refunded, or synced for an order, along with gateway response data, receipt data, and risk signals.

Parent hierarchy:

• Payments & Billing
• Order Payment Capture And Reconciliation
• Order Payment

Primary implementation paths:

• packages/framework/src/Models/OrderPayment.php
• packages/framework/src/Http/Controllers/Api/Admin/OrderPaymentsController.php
• packages/framework/src/Actions/Stripe
• packages/framework/src/Actions/PaymentGateway

What Users Can Do With It

Direct capabilities

Operators can:

• list, create, and show order payments under an order
• create manual payments
• charge a saved Stripe customer card
• transfer a payment to another order as a superadmin
• sync a Stripe-backed payment record with gateway data

Indirect capabilities

Other workflows use OrderPayment to:

• collect payment through Stripe checkout
• collect payment through credit-line confirmation flows
• determine refundable balance and amount due
• create refund records and payment risk records

Things users cannot do directly

This pass did not find a standalone packaged admin page dedicated only to order-payment management. In practice, payments are consumed through order review flows, API-backed order tools, checkout links, and host-app payment panels.

Where It Is Managed

Channel	Role	Notes
Admin nested orders.payments API	Direct	Main packaged CRUD-like entry for creation and review
Admin order confirmation and checkout flows	Parent-owned	Payment collection starts from order workflows
Storefront checkout	Indirect	Stripe checkout produces payment records through sync
Storefront payment methods	Indirect	Saved cards support future payment capture but are not payment records

Sources:

• packages/framework/src/Http/Controllers/Api/Admin/OrderPaymentsController.php
• packages/framework/src/Actions/Stripe/ChargeStripeCustomerCard.php
• packages/framework/src/Actions/Stripe/SyncStripeCheckoutToOrderPayment.php
• packages/storefront/src/Livewire/Storefront/MyAccount/PaymentMethods/Table.php

Channel-Level Field Coverage

Admin create flow

Creating an order payment validates:

• payment_gateway_type
• payment_method_type for manual payments
• payment_reference_number for manual payments
• customer_card_id for Stripe saved-card charges
• amount

Source:

• packages/framework/src/Http/Controllers/Api/Admin/OrderPaymentsController.php

Stored payment fields

The model stores operational fields such as:

• payment_gateway_id
• sc_object_id
• amount
• amount_captured
• amount_refunded
• currency
• receipt_number
• receipt_url
• payment_method_details
• status
• risk_level
• risk_score
• gateway_response
• processed_at

Sources:

• packages/framework/src/Models/OrderPayment.php
• packages/framework/src/Http/Resources/Admin/OrderPaymentResource.php

Configuration And Data Model

Key model characteristics:

• soft-deletable
• UUID-based
• activity-logged
• touches the parent order when changed
• stores gateway payloads and risk metadata as JSON

Important relationships:

• order()
• paymentGateway()
• orderReturns()
• orderRefunds()

Source:

• packages/framework/src/Models/OrderPayment.php

Relationships

OrderPayment directly connects:

• orders
• payment gateways
• refunds
• return-linked refund allocations

Practical dependents:

• amount-due calculation
• refund eligibility
• payment risk review
• accounting export

Rules And Downstream Effects

Amount-due guardrails

Admin payment creation blocks payments larger than the current order amount due.

Sources:

• packages/framework/src/Http/Controllers/Api/Admin/OrderPaymentsController.php
• packages/framework/src/Models/Order.php

Manual and credit-line payment semantics

Manual and credit-line payment actions create local success-state payment records immediately, while manual payments require a unique reference number per order.

Sources:

• packages/framework/src/Actions/PaymentGateway/Manual/CreateOrderPayment.php
• packages/framework/src/Actions/PaymentGateway/CreditLine/CreateOrderPayment.php

Stripe sync side effects

Stripe charge and checkout sync flows can:

• create or update the order payment record
• capture gateway receipt and risk details
• create OrderRisk records from Stripe outcome data
• recalculate the order
• sync customer cards after successful checkout

Sources:

• packages/framework/src/Actions/Stripe/ChargeStripeCustomerCard.php
• packages/framework/src/Actions/Stripe/SyncStripeCheckoutToOrderPayment.php

Refundability

The where_is_refundable scope depends on the related gateway allowing refunds.

Source:

• packages/framework/src/Models/OrderPayment.php

Integrations And Automation

Payment collection

Order payments can originate from:

• Stripe checkout
• Stripe saved-card charges
• manual payment entry
• credit-line creation
• imported or synced Stripe charges

Sources:

• packages/framework/src/Actions/Stripe/CreateStripeCheckout.php
• packages/framework/src/Actions/Stripe/ChargeStripeCustomerCard.php
• packages/framework/src/Actions/PaymentGateway/Manual/CreateOrderPayment.php
• packages/framework/src/Actions/PaymentGateway/CreditLine/CreateOrderPayment.php

Transfer and sync tooling

The shared admin API exposes:

• transferPayment
• syncPayment

for operator-level reconciliation or correction.

Source:

• packages/framework/src/Http/Controllers/Api/Admin/OrderPaymentsController.php

Where It Appears To End Users

OrderPayment is mostly an operator-facing and system-facing record.

Operators consume it through order review and payment collection tooling. Shoppers encounter it indirectly through checkout, saved cards, and downstream invoice or refund communication rather than through a packaged shared payment ledger page.

Current Documentation Takeaways

1. OrderPayment is the source of truth for captured, refunded, and risk-scored money movement on an order.
2. The strongest packaged entrypoint is the nested admin payment API, not a dedicated shared payment management page.
3. Checkout, saved cards, refunds, and amount-due calculations all converge on this record.

Open Questions

• This first pass did not inspect host-app payment panes that may render the shared orders.payments API in a richer operator UI.