Radial Integration | 2016
For processing asynchronous messages, Radial supports two flavors of integration: an AMQPS-based integration that uses the pull strategy and an HTTPS-based integration that uses the push strategy. Depending on the needs of your integration, you can choose to use either the push or the pull strategy. The push integration is an event callback (webhooks) framework that notifies clients when event messages are produced in Radial's internal systems.
Each store implementation can use only one of these integration strategies, push or pull, but not both.
The sequence diagram below covers the system interactions in Webhooks integration:
Default Event Messaging (Pull Strategy): An asynchronous message originates in Payment Service or Risk Service and is published to an externally exposed RabbitMQ queue. Radial provides the details of the AMQPS endpoint and queue name, along with credentials to connect to the queue and retrieve the messages. Using this information, you can connect to the RabbitMQ queue and collect the messages.
Webhooks Notification (Push Strategy): For clients that prefer to be notified of the events instead, a webhooks listener subscribes to the RabbitMQ queue. As soon as the message shows up on the AMQP endpoint, the webhooks service pulls down the message and submits it to the URLs registered for your store. The client at the registered URL is expected to acknowledge the message receipt with an HTTP 200 status response. As soon as the acknowledgment is received, the message is removed from the RabbitMQ queue.
Error Flow: If the client's URL is down or the service receives a 400 or 500 error, then an error alert is produced and the message is flagged for a retry. A retry job then periodically retries to submit the message to the client URL, until the max duration is reached. If the client acknowledges the message during the retry period, then the message is removed from the queue. If client endpoint is down after max retry duration, the service stops retrying and alerts Radial team to reach out to the customer and confirm the endpoint status.
By default, each store is set up with RabbitMQ queues. If you prefer to integrate using the Webhooks option, you must associate an https endpoint to each of the RabbitMQ queues from which you want to receive messages. Radial's payment portal application provides an interface where you can view the queue names set up for your store and register an https endpoint (and user credentials, which are needed for the POST HTTP/HTTPS call). The configuration is typically done through Radial's Customer Portal. After registering as a user in Radial's Customer Portal, you can configure a client URL, username, and password for a given route.
The event messages posted to the HTTPS endpoints are slightly different from the messages that reside on the RabbitMQ. The messages that get posted back are consolidated into a list schema to prevent chattiness in the HTTPS callbacks. For details of the list schemas, see Payment Settlement Status List Event, Payment Authorization Cancel List Event, and Risk Assessment List Event.
Copyright © 2017 Radial. All rights reserved.