fluentcart-orders-transactions
Implements and audits FluentCart order, order-item, transaction, status, payment-settlement, refund, renewal-order, and lifecycle-hook behavior. Use when reading or mutating fct_orders or fct_order_transactions, selecting order_created, order_paid, order_paid_done, order_payment_
Install
npx skills add https://github.com/Lonsdale201/wp-agent-skills/tree/main/fluentcart/fluentcart-orders-transactions
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install lonsdale201-wp-agent-skills@llmmart
git clone https://github.com/Lonsdale201/wp-agent-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole lonsdale201/wp-agent-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
FluentCart orders and transactions
Drive order state from verified transactions and FluentCart lifecycle services. Do not equate order creation, successful payment, fulfillment, and subscription renewal.
Read order-event-map.md before attaching an irreversible side effect or updating any status.
Keep state dimensions separate
An order independently carries:
- status: commercial/fulfillment progression;
- payment_status: money progression;
- shipping_status: physical delivery progression;
- type: payment, subscription, renewal, and related variants;
- mode: test or live.
Use Status, StatusHelper, OrderResource, Orders, PaymentInstance, and Refund as appropriate. A direct update to payment_status does not create/reconcile a transaction, recount totals, complete the cart, reserve/release stock, activate a subscription, or dispatch the normal events.
Choose the event by guarantee
| Requirement | Use |
|---|---|
| Durable order aggregate created/updated for checkout | fluent_cart/order_created |
| Initial order transitioned to paid | fluent_cart/order_paid |
| Deferred normal post-payment processing point | fluent_cart/order_paid_done |
| Payment attempt became failed | fluent_cart/order_payment_failed |
| Refund recorded and totals/status synchronized | fluent_cart/order_refunded |
| Any subscription renewal settled | fluent_cart/subscription_renewed |
| Store-managed renewal invoice transitioned to paid | fluent_cart/renewal_paid |
| One status dimension changed | fluent_cart/_status_changed |
order_created does not mean paid. order_paid is synchronous and its internal listener recounts order/customer state and may create a WP user. order_paid_done is emitted later by Action Scheduler after a valid paid order is reloaded. Use it for third-party fulfillment/integration work that belongs after the standard deferred path.
Never hook business logic to fluent_cart/order_paid_async_private_handle. Core labels it private. The legacy misspelled ansyc variant exists only to drain old queued jobs.
Make event callbacks replay-safe
add_action('fluent_cart/order_paid_done', static function (array $data): void {
$order = $data['order'] ?? null;
if (!$order || $order->mode !== 'live') {
return;
}
// Atomically claim an addon-owned idempotency record keyed by order ID
// and operation before sending or granting anything.
});
StatusHelper atomically claims the pending-to-paid transition to reduce webhook and browser-confirmation races. That does not make downstream callbacks exactly-once. Store an addon-owned operation key and make retries converge.
Handle transactions and refunds
- Use transaction IDs/UUIDs in the correct namespace; do not use an invoice number as a provider idempotency key.
- Verify provider object, signature, currency, amount, mode, order/customer reference, and prior processed state.
- Reconcile through StatusHelper instead of announcing paid from a browser redirect.
- Use Refund::processRefund() for a local/admin initiated refund and the gateway's processRefund implementation for the provider operation.
- Use Refund::createOrRecordRefund() for webhook reconciliation; it deduplicates by provider refund ID and can match a pending local refund.
- Keep all amounts integer minor units and enforce both order and transaction refundable ceilings.
- Test partial, full, repeated, and out-of-order refund notifications.
Query and authorize
- Scope customer-facing queries by the resolved customer, not UUID alone.
- Treat Order.uuid as an opaque lookup value but not a guaranteed database unique key; legacy rows and the current schema use a non-unique index.
- Eager-load only the relationships needed by the job.
- Bound report/admin queries and preserve mode/currency distinctions.
- Redact provider payloads, customer PII, and payment tokens from logs.
Cross-references
- Use fluentcart-payment-gateways for provider confirmation and webhooks.
- Use fluentcart-subscriptions-renewals for renewal semantics.
- Use fluentcart-integrations-jobs for outbound feeds and queues.
References
- Official order hooks: https://dev.fluentcart.com/hooks/actions/orders/
- Verified Free source paths:
- fluent-cart/app/Models/Order.php
- fluent-cart/app/Models/OrderItem.php
- fluent-cart/app/Models/OrderTransaction.php
- fluent-cart/api/Resource/OrderResource.php
- fluent-cart/app/Helpers/Status.php
- fluent-cart/app/Helpers/StatusHelper.php
- fluent-cart/app/Events/Order/
- fluent-cart/app/Services/Payments/Refund.php
- fluent-cart/app/Hooks/actions.php
Files (wp-agent-skills)
-
agents
-
openai.yaml 325 B
interface: display_name: "FluentCart orders and transactions" short_description: "Use correct settlement, status, refund, and event flows" default_prompt: "Use $fluentcart-orders-transactions to implement or audit this order workflow with correct status dimensions, transaction reconciliation, hooks, and idempotency."
-
-
references
-
order-event-map.md 2.5 KB
# FluentCart 1.6.0 order event map EventDispatcher runs internal listeners before firing the public hook. Event payloads are generally one associative array, not separate positional objects. Confirm accepted arguments against the event's toArray() method. ## Main order events | Hook | Core payload | |---|---| | fluent_cart/order_created | order, prev_order, customer, transaction | | fluent_cart/order_paid | order, customer, transaction | | fluent_cart/order_paid_done | order, transaction, customer; subscription when resolved | | fluent_cart/order_payment_failed | inspect event source before use | | fluent_cart/order_refunded | order plus refund data from OrderRefund | | fluent_cart/order_fully_refunded | same refund event family | | fluent_cart/order_partially_refunded | same refund event family | | fluent_cart/order_updated | order/change context from event | ## Status events OrderStatusUpdated does not fire its generic order_status_updated hook automatically. It emits according to its type: - fluent_cart/payment_status_changed_to_{new_status} - fluent_cart/payment_status_changed - fluent_cart/shipping_status_changed_to_{new_status} - fluent_cart/shipping_status_changed - fluent_cart/order_status_changed_to_{new_status} - fluent_cart/order_status_changed Payload: order, old_status, new_status, manageStock, activity. ## Paid sequence ~~~text successful transaction(s) -> StatusHelper::syncOrderStatuses() -> atomic pending-to-paid claim -> OrderPaid (initial order, not renewal) -> receipt number -> internal recount/user listener -> fluent_cart/order_paid -> private Action Scheduler action -> reload paid order and delete queue marker -> fluent_cart/order_paid_done ~~~ Renewal invoices intentionally do not repeat this initial-order sequence. Gateway-managed renewal and store-managed renewal paths converge on SubscriptionRenewed, while fluent_cart/renewal_paid is limited to a store-managed invoice's unpaid-to-paid transition. ## Refund sequence Refund::processRefund(): 1. validates positive amount and order/transaction refundable ceilings; 2. creates a refund transaction linked to the parent in meta; 3. updates parent refunded_total; 4. invokes the registered gateway unless marked manual; 5. stores the provider refund ID when returned; 6. dispatches OrderRefund, which synchronizes totals/status and emits full or partial hooks. Do not grant stock restoration or access revocation twice when a provider webhook later confirms the same refund.
-
-
SKILL.md 5.4 KB
--- name: fluentcart-orders-transactions description: >- Implements and audits FluentCart order, order-item, transaction, status, payment-settlement, refund, renewal-order, and lifecycle-hook behavior. Use when reading or mutating fct_orders or fct_order_transactions, selecting order_created, order_paid, order_paid_done, order_payment_failed, order_refunded, or dynamic status hooks, marking an order paid, reconciling a webhook, refunding money, or preventing duplicate fulfillment and incorrect status transitions. metadata: wp-skills-author: "Soczó Kristóf" wp-skills-contact: "mailto:lonsdale201@hotmail.com" wp-skills-plugin: "fluent-cart" wp-skills-plugin-version-tested: "1.6.0" wp-skills-wp-version-tested: "7.0.2" wp-skills-php-min: "7.4" wp-skills-last-updated: "2026-08-06" --- # FluentCart orders and transactions Drive order state from verified transactions and FluentCart lifecycle services. Do not equate order creation, successful payment, fulfillment, and subscription renewal. Read [order-event-map.md](references/order-event-map.md) before attaching an irreversible side effect or updating any status. ## Keep state dimensions separate An order independently carries: - status: commercial/fulfillment progression; - payment_status: money progression; - shipping_status: physical delivery progression; - type: payment, subscription, renewal, and related variants; - mode: test or live. Use Status, StatusHelper, OrderResource, Orders, PaymentInstance, and Refund as appropriate. A direct update to payment_status does not create/reconcile a transaction, recount totals, complete the cart, reserve/release stock, activate a subscription, or dispatch the normal events. ## Choose the event by guarantee | Requirement | Use | |---|---| | Durable order aggregate created/updated for checkout | fluent_cart/order_created | | Initial order transitioned to paid | fluent_cart/order_paid | | Deferred normal post-payment processing point | fluent_cart/order_paid_done | | Payment attempt became failed | fluent_cart/order_payment_failed | | Refund recorded and totals/status synchronized | fluent_cart/order_refunded | | Any subscription renewal settled | fluent_cart/subscription_renewed | | Store-managed renewal invoice transitioned to paid | fluent_cart/renewal_paid | | One status dimension changed | fluent_cart/{dimension}_status_changed | order_created does not mean paid. order_paid is synchronous and its internal listener recounts order/customer state and may create a WP user. order_paid_done is emitted later by Action Scheduler after a valid paid order is reloaded. Use it for third-party fulfillment/integration work that belongs after the standard deferred path. Never hook business logic to fluent_cart/order_paid_async_private_handle. Core labels it private. The legacy misspelled ansyc variant exists only to drain old queued jobs. ## Make event callbacks replay-safe ~~~php add_action('fluent_cart/order_paid_done', static function (array $data): void { $order = $data['order'] ?? null; if (!$order || $order->mode !== 'live') { return; } // Atomically claim an addon-owned idempotency record keyed by order ID // and operation before sending or granting anything. }); ~~~ StatusHelper atomically claims the pending-to-paid transition to reduce webhook and browser-confirmation races. That does not make downstream callbacks exactly-once. Store an addon-owned operation key and make retries converge. ## Handle transactions and refunds - Use transaction IDs/UUIDs in the correct namespace; do not use an invoice number as a provider idempotency key. - Verify provider object, signature, currency, amount, mode, order/customer reference, and prior processed state. - Reconcile through StatusHelper instead of announcing paid from a browser redirect. - Use Refund::processRefund() for a local/admin initiated refund and the gateway's processRefund implementation for the provider operation. - Use Refund::createOrRecordRefund() for webhook reconciliation; it deduplicates by provider refund ID and can match a pending local refund. - Keep all amounts integer minor units and enforce both order and transaction refundable ceilings. - Test partial, full, repeated, and out-of-order refund notifications. ## Query and authorize - Scope customer-facing queries by the resolved customer, not UUID alone. - Treat Order.uuid as an opaque lookup value but not a guaranteed database unique key; legacy rows and the current schema use a non-unique index. - Eager-load only the relationships needed by the job. - Bound report/admin queries and preserve mode/currency distinctions. - Redact provider payloads, customer PII, and payment tokens from logs. ## Cross-references - Use fluentcart-payment-gateways for provider confirmation and webhooks. - Use fluentcart-subscriptions-renewals for renewal semantics. - Use fluentcart-integrations-jobs for outbound feeds and queues. ## References - Official order hooks: <https://dev.fluentcart.com/hooks/actions/orders/> - Verified Free source paths: - fluent-cart/app/Models/Order.php - fluent-cart/app/Models/OrderItem.php - fluent-cart/app/Models/OrderTransaction.php - fluent-cart/api/Resource/OrderResource.php - fluent-cart/app/Helpers/Status.php - fluent-cart/app/Helpers/StatusHelper.php - fluent-cart/app/Events/Order/ - fluent-cart/app/Services/Payments/Refund.php - fluent-cart/app/Hooks/actions.php
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.