Skip to main content

Message Flow

IP.Frame will present the user with a choice of payment methods and guide them through the process.

IP.Frame Message Flow​

The following diagram shows the message flow and interactions involved in an Payen Platform transaction and the responsibilities of each party involved.

image

  1. The merchant gathers information about the client and the purchase and constructs the request to send directly to the Payen Platform to initiate the transaction.This is a server to server request to eliminate the possibility of message tampering or exposing sensitive information via the customer’s browser.
  2. A request is received by the Payen Platform. The request is validated and a request key is generated for this transaction. The request key is a merchant unique, secure, indeterminable value that will be used to identify the transaction in the next step.
  3. Through an iframe embedded in the merchant’s web site, the source of the iframe is set to a URL consisting of the IP.FrameURLand, among other values, the request key from the previous step. The Payen Platform receives the parameters, validates the request and displays the IP.Frame to the customer.
  4. The IP.Frame takes control, adding new payment methods or amending existing ones. The client will choose a payment method to complete the transaction
  5. The customer’s payment method is authorised using the details provided in step 1.
  6. The IP.Frame will control user experience based on the response of the authorisation. If the transaction was declined more options will be presented to the customer in an effort to authorise the payment using correct details or other payment methods.
  7. A POST message containing the response key is sent back to the merchant via the customer’s browser. The merchant is now back in control of the customer and can complete the order process or display feedback to the customer.
  8. If configured to do so, the Payen Platform can send an asynchronous notification to the merchant, server to server, containing the result of the entire process so that the relevant completion message can be displayed to the customer. This is a message containing all the details of the transaction in the same format as would be received in a payment status response (as per step 10). This method of notification is designed to make sure that the response is always received by the merchant, even if there are browser/connection problems during the previous step.
  9. If an asynchronous notification has not been received, or the system is not configured to send one, or if one was not requested, the merchant can construct a status request using the response key from step 7to obtain the detailed response of the transaction. This request is made directly to the Payen Platform, server to server, to ensure that there are no sensitive details passed through the customer’s browser in the response and to eliminate the possibility of the response being tampered with. This method of retrieving details of the response also ensures that the IP.Frame is aware that the merchant received the response key and so both parties can confirm that they have received the necessary response. It is possible that the IP.Frame can take action if no status request is received for a given response key, so a successful payment can be reversed if we have not received confirmation that the merchant has received the response.
  10. The result of the entire process is sent back to the merchant so that the relevant completion message can be displayed to the customer. The response is a message containing all the details of the transaction.