Integrating PayFast with Inventory Systems
INTEGRATION ROUTE
Make payment confirmation a controlled event
A browser redirect is not dependable evidence of payment. Map the verified gateway notification to one WooCommerce transition and one downstream stock action, with duplicate-event protection throughout.
01 · VERIFY
Trust the server notification
Validate the payment event and preserve its reference independently of what happens in the shopper's browser.
02 · COMMIT
Trigger stock once
Send one paid order to the inventory owner and reject repeated imports carrying the same external reference.
03 · RECOVER
Design for delayed and reversed events
Give pending payments, cancellations and refunds explicit states, owners and safe reversal rules.
Use a repeated notification as a safety test
The integration passes only when replaying the same event does not create another order, stock deduction or finance entry.
Integration principle
Payfast should confirm money, WooCommerce should own the ecommerce order, and the inventory system should own available stock unless the documented design says otherwise. Use a verified server notification and an idempotent order update; never deduct stock twice because both the browser return and payment notification fired.
This guide covers the control points between payment and stock. For an implementation review, see Mitrend ecommerce systems; for payment balancing, use the reconciliation guide.
Map each event to one system owner
| Event | System of record | Required control |
|---|---|---|
| Checkout created | WooCommerce | Unique order number and immutable line snapshot |
| Payment notification | Payfast plus gateway extension | Signature/notification validation and duplicate-event protection |
| Order becomes paid | WooCommerce | One transition that triggers downstream fulfilment |
| Stock committed | Inventory source | External reference prevents a second deduction |
| Refund or cancellation | Gateway and WooCommerce | Documented reversal or quarantine rule |
Configuration sequence
- Obtain the Merchant ID, Merchant Key and passphrase from Payfast developer settings; store them only in the payment configuration.
- Configure the Payfast WooCommerce method in sandbox first and enable logging during controlled testing.
- Define which WooCommerce status sends the order to inventory. Use the paid state, not merely order creation, unless the business deliberately reserves stock earlier.
- Send the WooCommerce order number as the external reference and reject duplicate imports in the inventory connector.
- Separate payment failure, payment pending and paid states so staff do not release unpaid stock.
- Test a successful payment, abandoned redirect, duplicate notification, delayed notification, partial refund and cancelled order.
Do not let the customer browser be the control
A shopper can close the tab before returning from the gateway, or the return page can load while a server notification is delayed. The integration needs a server-side confirmation and a recovery process for orders that remain pending beyond the expected window.
Go-live acceptance checks
For each test, retain the Payfast transaction reference, WooCommerce order note, inventory transaction and resulting available quantity. The test passes only if repeating the same gateway notification does not create another order, stock deduction or finance entry.
Sources checked
Reviewed by
Mitrend Digital editorial team
2026-07-16
Evidence used for this page
Reviewed against Payfast’s current WooCommerce setup guidance and WooCommerce order/refund behaviour. Includes an original event and ownership map.
Turn the guide into a practical next step
This resource provides general implementation guidance. Verify platform settings, tax, legal, payment and operational requirements against the current business context before making a live change.
Implementation detail: PayFast and inventory integration
A payment redirect is not proof that an order is paid. The integration must reconcile the gateway event, WooCommerce order, stock movement and accounting record while preventing duplicate callbacks or ambiguous exceptions.
Decisions to make before changing the system
- Which gateway event is authoritative for paid, failed, cancelled and refunded states?
- How is a duplicate callback identified and safely ignored?
- When is stock reserved, reduced, released or restored?
- Who investigates an order with payment evidence but no matching order status?
- Which fees, refunds, chargebacks and settlement dates reach finance?
- How are guest checkout details matched to the customer record?
- What happens when the gateway, store or inventory system is temporarily unavailable?
- Which test evidence is retained for every release or gateway update?
A controlled implementation sequence
- Map gateway events to order statuses, customer messages, stock actions and finance fields.
- Create idempotency and retry rules before enabling live callbacks.
- Run success, failure, cancellation, timeout, duplicate and refund tests with known references.
- Compare gateway transactions to WooCommerce orders and inventory adjustments for a sample window.
- Document the manual recovery route when a callback or stock update is missing.
- Monitor exceptions after launch and schedule a retest when the gateway or plugin changes.
Acceptance controls that protect the outcome
| Control | Implementation detail |
|---|---|
| Event map | Every event has one status, owner, customer message and downstream action. |
| Idempotency | Repeating the same callback does not duplicate an order, payment or stock movement. |
| Stock | Reservation and release rules match the fulfilment promise shown to the customer. |
| Reconciliation | Gateway amount, fees, refunds and settlement can be traced to the order and bank record. |
| Recovery | A missing event has a documented search, correction and customer-communication path. |
| Monitoring | Exceptions are visible through a report or queue with an accountable owner. |
Retain gateway references, order IDs, callback payload samples, status changes, stock events and reconciliation results. Redact credentials and personal data while keeping enough detail to reproduce the test.
Avoid using a thank-you page visit as the accounting trigger. Customers can close a page, callbacks can retry, and a successful redirect can still be followed by a failed settlement.
What a useful handover includes
- A gateway-to-order status matrix with retry and duplicate rules.
- A test pack covering success, failure, refund and timeout scenarios.
- A reconciliation worksheet for orders, fees, refunds and settlements.
- A recovery runbook for missing callbacks, mismatched stock and customer queries.
- A permissions and secret-rotation note owned by the business.
- A change log for gateway, WooCommerce, inventory and accounting updates.
The integration is ready when another person can trace a payment from gateway evidence through order status, stock and finance without guessing which screen is authoritative.
Design for missing events
Every payment integration needs a path for the event that never arrives. The recovery operator should search the gateway by reference, inspect the WooCommerce order, check stock and decide whether a controlled correction is safe. If the event may still be retried, the correction must not create a duplicate payment or movement. Record the customer message and the finance treatment as part of the same case. A small exception queue with age, value and owner is more useful than a dashboard that only shows successful transactions.
- Search by gateway reference, order ID, amount and time window.
- Confirm whether the payment is settled, pending, reversed or refunded.
- Check stock reservation and fulfilment status before releasing or correcting inventory.
- Record the correction, reviewer and customer update in one case.
- Use recurring cases to improve retry, alerting or idempotency rules.