Handling No-Response Situations

The following best practices are recommended for handling scenarios where no response is received from the Radial web service layer.

Inventory Request

If no response is received from the web service layer for an inventory quantity get request or an inventory allocate request, order capture and submission should continue as normal. Inventory is confirmed and assigned by the order management system as part of order processing. Orders submitted to the order management system that do not have available inventory on-hand will either be moved to a backorder status (if supported) or canceled. The consumer will be notified by email if either of these scenarios occurs.

Address Validate Request

If no response is received from the web service layer for an address validate request, order capture and submission should continue as normal. Shipping addresses will be confirmed at the time an order is shipped. If a valid address cannot be determined, the order is undeliverable and will be canceled. The consumer will be notified by email if this occurs.

Tax Quote Request

If no response is received from the web service layer for a tax quote request, order capture and submission should continue, however no tax should be displayed to the consumer during the remainder of checkout and a message should be displayed to the consumer in the ordering interface, for eample, Taxes could not be calculated at this time, but will be displayed in future communications containing details about the order. When the order create request is made, it should contain the additional elements in the XML <TaxHeader><Error>true</Error></TaxHeader>. This will indicate that taxes were not calculated for the order and will trigger the order management system to recalculate taxes during order processing in that system.

Credit Card Authorization Request

This case applies only to non-fixed-tender types, such as credit cards. If no response is received from the web service layer for a credit card authorization request order capture and submission should continue as normal.

When submitting the order, the <PaymentAccountUniqueId> value should contain the un-tokenized payment account number (PAN), or credit card number, the isToken attribute element should be set to a value of false, and the <Authorization><ResponseCode> element must have a value of PaymentProcessorTimeout. This will notify the order management system that the tender was never authorized and will trigger a new authorization of the tender during order processing. For this case, all values for each element in the <PaymentContent> must be supplied, including the same <PaymentSessionId> and <PaymentRequestId> values used when making the initial request from the ordering interface. Additionally, valid values should be supplied for the <CreateTimeStamp>, <Amount>, <ExpirationDate> elements, and the <Authorization><AuthorizedAmount> element should contain a value of 0.00. All other elements in the <Authorization> block should be submitted as empty elements with no value specified.

Stored-Value Redemption Request

This case applies only to fixed-tender types, such as gift cards and online gift certificates. If no response is received from the web service layer for a stored-value redemption request, order submission should be aborted.

The order management system expects orders containing fixed-tender payments to have been redeemed by the ordering interface. If the order management system receives an order submission that contains a fixed-tender type as a payment and that tender has not been successfully redeemed prior to order submission, the order management system will not redeem the fixed-tender as part of its processing and the order will fail order processing.

When a fixed-tender cannot be redeemed by the ordering interface due to the lack of a response from the web service layer, order submission should be aborted and the consumer should be messaged that the tender could not be redeemed at the time of order submission. The consumer should then be taken back to the payment options screen and prompted to supply an alternative method of payment for the order.

PayPal Authorization Request

If no response is received from the web service layer for a PayPal authorization request, order submission should be aborted. PayPal orders must have a valid authorization in order to be correctly processed. If no authorization is obtained for a PayPal order, this should be treated in the same way as a failed stored-value redemption request.

Order Create Request

If no response is received from the web service layer for an order create request, retry attempts should be made to submit the order.

The method of implementing retry attempts is dependent on the ordering interface; however, it is recommended that the order message be stored by the ordering interface and a retry attempt is made once every half-hour after the original order submission failure. The consumer should be messaged to let them know that there was an issue in capturing their order, but additional attempts will be made and the consumer will be notified after the successful creation of their order.

It is recommended that a minimum of three retry attempts be made. After several successive retry attempts have failed due to a lack of response from the web service layer, Radial should be notified immediately. If a retry attempt is made and receives an valid error response from the web service layer, the order should be canceled, removed from the retry queue, and the consumer should be notified.

If an order is successfully submitted on a retry attempt, that order should be removed from the retry queue. Subsequent resubmissions of an order with the same order number will always result in an error and the order will not be created a second time in the order management system, since the order already exists (this is expected behavior).