In the case of custom payment integrations, captures (settlements) and refunds, as well as any other payment notifications, will be requested by the OMS. The sales channel remains responsible for taking authorizations at the time of checkout. After sucessful authorizations only a token will be passed down to OMS to avoid that sensitive information, such as credit card numbers, will be passed down. All following actions will be done using that token.
In the case of offline payments, OMS will not take any action regarding payments. 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 backoffice
- 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 payments should be used if the payment process is aleady managed by an external system. Typical examples are marketplaces or B2B channel, which have their own payment processes.
For more information, see the Offline payments page.
Payment event status
This table shows all the payment events statuses that are available in your OMS:
|Payment Event Status||Payment Events||Description|
||All payment events||The OMS was able to deliver the payment request to its destination successfully. Destinations use the Radial payment API or Reno.|
||All payment events||The OMS received a positive response for the initial payment request.|
||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.|
||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.|
||All payment events||The payment event will retried later through the Retry On Hold job. This is a recovery backdoor.|
||Authorizations only||Payment was authorized successfully.|
These different statuses can occur throughout the order life of your OMS, depending on the payment integration used.
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.