How it Works
Cardinal Cruise uses Songbird.js to perform most of the heavy lifting on behalf of our customers. It will handle all device data collection and communication with our Cardinal Centinel platform, as well as the user experience to the consumer for both CCA and Alternative Payment brands.
The diagram below shows the high-level event execution order of a transaction from the merchant's perspective. The enumerated events do not map to the integration steps found within this document. The enumerated events are simply to help illustrate the order events occur in during a transaction.
Step 1: JWT Creation
Our Cardinal Cruise integration uses JWT's (JSON Web Token) as the method of authentication between the merchant and Cardinal servers. A valid JWT is required to properly initialize Songbird.js and any JWT library that supports JWS (JSON Web Signature) can be used. If you don't currently have a JWT library, we recommend reviewing some of the options available at jwt.io.
Please note that each claim key is case sensitive.
|jti||JWT Id - A unique identifier for this JWT. This field should change each time a JWT is generated.|
|iat||Issued At - The epoch time in seconds of when the JWT was generated. This allows us to determine how long a JWT has been around and whether we consider it expired or not.|
|iss||Issuer - An identifier of who is issuing the JWT. We use this value to contain the Api Key identifier or name.|
The merchant SSO OrgUnitId
|Payload||The JSON data object being sent to Cardinal. This object is usually an Order object|
The following claims are available for use but are not currently required for a valid JWT:
|ReferenceId||This is a merchant supplied identifier that can be used to match up data collected from Cardinal Cruise and Centinel. Centinel can then use data collected to enable rules or enhance the authentication request.|
|ObjectifyPayload||A boolean flag that indicates how Centinel Api should consume the Payload claim. When set to true, this tells Centinel Api the Payload claim is an object. When set to false, the Payload claim is a stringified object. Some Jwt libraries do not support passing objects as claims, this allows those who only allow strings to use their libraries without customization|
|exp||Expiration - The numeric epoch time that the JWT should be consider expired. This value is ignored if its larger than 2 hrs. By default we will not consider any JWT older than 2 hrs.|
The following claims are conditionally required when doing some transactional flows:
|Claim Name||Description||Flow Required|
|ConfirmUrl||The merchant endpoint that will receive the post back from the payment brand that contains the Centinel API response JWT describing the result of redirecting to the payment brand.||Redirect|
JWT Payload Example
Below is an example of the JSON content of a basic JWT Payload where we are passing an object within the Payload claim:
Below is an example of the JSON content of a basic JWT Payload where we are passing a string within the Payload claim:
Adding Songbird to Your Front End
Now that we're able to authenticate with Cardinal servers using JWTs, we can start adding the Songbird library to your site.
Step 2: Include the Script
Songbird.js is added to your site just like any other client side script - through a script tag. For performance reasons, it's generally a good practice to put script includes after all of your content, but before the closing HTML body tag. This will help prevent the page from blocking other resources like image downloading while downloading scripts. Just be sure that the Songbird script include comes before the script tag containing the rest of the Songbird steps.
Step 3: Configure It
There are a number of configuration options for Cardinal Cruise. Using the Cardinal.configure() function allows you to pass a configuration object into Songbird. You should only call this function once per page load. During your development, you will most likely want control over the logging volume from the library. You can do this through the use of Cardinal.configure, as seen below:
Step 4: Listen for Events
This function sets up an event subscription with Songbird to trigger a callback function when the event is triggered by Songbird. A valid subscription requires a namespace and a callback function to be run when the event is triggered. Calling this function with the same namespace multiple times will result in a callback being triggered multiple times. To read more on events and how the subscription and publisher model works in Songbird, refer to the Songbird API Reference section on Cardinal.on().
You subscribe to an event using the Cardinal.on() function structured like:
Using actual values it looks something like this:
This optional event triggers when Songbird has successfully initialized, after calling the Cardinal.setup() function. This event will not trigger if an error occurred during your Cardinal.setup() call (this includes a failed JWT authentication) and this event will only trigger once per page load. If your callback gets executed, you know that Songbird is available to run transactions. This function will receive 2 arguments that describe the loaded state of Songbird and the current session identifier.
This event is triggered when the transaction has been finished. This is how Songbird hands back control to the merchant's webpage. This event will include data on how the transaction attempt ended and should be where you place logic for reviewing the results of the transaction and making decisions regarding next steps. The ActionCode field should be used to determine the overall state of the transaction. Additional information can be found in the fields ErrorNumber and ErrorDescription if the ActionCode indicates an issue was encountered. On first pass, we recommend that on an ActionCode of 'SUCCESS' you send the response JWT to your backend to be verified. There is more on verifying JWT's in the next section. When you add CCA or an Alternative Payment brand, additional details will be provided on how to handle the specific response values for each. Each additional payment brand you add may return some values that are specific to that payment brand, and may require special handling logic.
Step 5: Initialize It
Next we need to authenticate your system and set up CCA or all the Alternative Payment brands your account is configured for. Calling
Cardinal.setup() will initiate the communication process with Cardinal to ensure your consumers' experience is seamless. By the time the consumer is ready to checkout, all necessary pre-processing will be completed. You can listen for the payments.setupComplete event to be notified when Songbird has finished initializing. Check out the Listen for Events section for more. You should only call this function once per page load.
Cardinal.setup does not catch errors. Use the payments.validated event mentioned in Step 4 instead.
Next: Add Consumer Authentication or an Alternative Payment Brand
You have now completed a base implementation of Songbird and you're ready to add Cardinal Consumer Authentication or an Alternative Payment brand and start running some transactions. Select CCA or the Alternative Payment brand you'd like to add from the menu on the left or below.