Payment | Magento Order Management Documentation (Archived)

The Magento Order Management System (OMS) can handle payments via Custom payment integrations or the Offline method.

Custom payment integrations (captures and refunds), as well as any other payment notifications, will be requested by the OMS. The sales channel is responsible for taking authorizations at the time of checkout. After successful authorizations a token will be passed down to the OMS to avoid passing sensitive information, such as credit card numbers. All of these actions are completed using that token.

For offline payments, The OMS will not take any payment actions. The payment of orders is fully managed outside of the OMS.

Custom payment integrations

Custom payment integrations allow you to integrate with any payment service provider by adapting standard OMS messages to the format expected by the payment service provider. More details about the integration are available in our Custom Payment Integration page.

Custom integrations support the following features.

Capture of the amount
- After the last shipment it will capture the amount of the shipped items (including the shipping costs), which may be less than the authorized amount (for cancelled items).
- After X days, or after the last shipment, (the first event occurring):
  
  After X days the objective is to capture payment before the authorization expires (some cards like Carte Bleue In France expire after six days) even though the order is not yet shipped. A refund will be triggered if any lines are subsequently canceled.
  
  After the last shipment it will capture the amount of the shipped items, including the shipping costs, which may be less than the authorized amount (for canceled items).
- Before the first shipment request is sent (a refund will be triggered if any lines are subsequently cancelled).
- After each shipment (for multi-captures), it captures the amount of the shipped items once a day. For partially shipped orders, it captures the remaining amount right after the last shipment.
Refunds due to cancellations, appeasements or returns
Manual retries for failed refunds in the OMS Admin
Notifications of capture confirmations (may be multiple days depending on the payment method), which can be monitored if they are not received in a timely fashion

Offline method

Offline payments should be used if the payment process is already managed by an external system. Typical examples are marketplaces or B2B channels, which have their own payment processes.

See Offline payments for more info.

Payment event status

Payment events statuses available in your OMS include:

Payment Event Status	Payment Events	Description
`AUTHORIZED`	Authorizations only	Payment was authorized successfully.
`DECLINED`	Authorizations only	The OMS was not able to perform the payment operation due to a soft rejection (such as insufficient funds).
`FAULT`	All payment events	The OMS was not able to deliver the payment request to its destination, most usually due to a technical error. This status is picked by the systemic retry process.
`FAILURE`	All payment events	The OMS was not able to perform the payment operation, such as for a capture. When retry attempts are expired this status is also used.
`PENDING`	All payment events	The payment event will retried later through the Retry On Hold job. This is a recovery backdoor.
`RECEIVED`	All payment events	The OMS was able to deliver the payment request to its destination successfully.
`REJECTED`	Authorizations only	The OMS was not able to perform the payment operation due to a hard rejection (such as suspected fraud).
`REVERSED`	All payment events	A previously successful operation has been reversed, such as for chargebacks issued from the bank.
`SUCCESS`	All payment events	The OMS received a positive response for the initial payment request.

These different statuses can occur throughout the order flow of your OMS, depending on the used payment integration.

Testing

No matter the method, we recommend extensive testing in staging and production prior to opening to the public. Sufficient time should be allocated for this important activity. With payments, production is always different than staging, even in subtle ways, due to the way real credit cards and banks process transactions.