Option 1 - ReturnUrl Response

The ReturnUrl option is a merchant defined URL that must go in the Transactional or Authentication JWT as a root level claim and it will be the location to which you receive the consumer session back after the Device Data Collection URL has completed processing or not.  After the Device Data Collection URL has completed, it will initiate a form post to the ReturnUrl.

Example of JWT with ReturnUrl Claim -

{ "jti": "f7c64630-a167-11e8-9db5-9f12cae676de", "iat": 1534432854, "iss": "Midas-NoDV-Key", "OrgUnitId": "564cdcbcb9f63f0c48d6387f", "ReferenceId": "c3989c38-6caf-410a-8965-459b1e814648", "ReturnUrl": "http://localhost:8189/cart/enterprise/collect-term", "Payload": { "OrderDetails": { "Amount": 1500, "CurrencyCode": 840, "OrderNumber": "asdf" } }, "ObjectifyPayload": true }

Based on the endpoint a merchant is integrated with, we will provide different responses.

  1. ReturnUrl Response (v1 Endpoint)

  2. ReturnUrl Response (v2 Endpoint)

The V1 and V2 profile completed objects are similar but V2 offers additional information about the data collection to allow merchants to make decisions based on the success or failure of certain data points. For example, if we were unable to collect `CardinalData` the merchant could opt to send the 9 required fields on the `cmpi_lookup` request to ensure a 3DS 2.0 transaction can still complete.