Eligibility Handover Journey
Learn how to handover a customer's eligibility check to NewDay for decisioning.
Overview
id
and customerRef
. These values are then encrypted into a JSON Web Token (JWT) and sent to NewDay's Acquisitions Web Application, enabling the customer to proceed seamlessly with their journey. This is what we refer to as the 'handover' process and the steps to build this journey are outlined below.Capture the required form data
- If the partner is hosting the quote form, they will need to capture all of the fields required for their specific product to check the customer's eligibility. The full set of available fields is detailed on the Create Application endpoint, along with any field validation. However, it should be noted that the required fields can vary depending upon the product and decisioning strategy, and the exact content should be determined by the lender's Product/Credit teams.
- If a partner is hosting a product page, dependent on the lender's specific requirements, it might need to include the "Summary Box" document detailing key product features.
- If the partner is hosting the quote form, dependent on the lender's specific requirements, it might need to include the eligibility check terms and conditions, and privacy policy. It may also need to capture the customer's assent that they have read and agreed to both the terms and conditions, and the privacy policy.
Create an Application
When the relevant customer details are captured, an application can be created by calling the Create Application endpoint. This endpoint response body will return the id
and customerRef
necessary to create a valid JWT token as mentioned earlier on the page.
Check Customer Eligibility
When the related application is created, the customer's eligibility can be checked by calling the Eligibility endpoint.
It is worth noting that any 500 response code errors when calling the createApplication or eligibility endpoints will need to be handled on the retailers side.
Handover to NewDay
Now that a valid application has been created and the eligibility checked, the application can be handed over to NewDay to complete the journey. As part of the handover to NewDay, a valid token must be provided in the URL. To generate a token, refer to the header and payload example illustrated below:
Below is the header and payload information:
Parameter | Location | Description | Format |
---|---|---|---|
alg (required) | Header | The token must be signed with an HS256 algorithm (HMAC with SHA-256). The key for both generating the signature and validating will be provided to you. | string |
typ (required) | Header | The token type is Json Web Token. | string |
id (required) | Payload | A 36-digit identifier that identifies the customer application in our databases. The application state property must be quoteAccept , quoteDecline or complex . | guid |
customerRef (required) | Payload | A 36-digit identifier that identifies your brand/product, this value will be provided to you. | guid |
exp (required) | Payload | The token expiration date is formatted as a number of seconds elapsed since epoch. Tokens should be valid for 5 minutes. | integer |
After creating and signing the JWT token, the customer should be redirected to the following URL as seen below. NewDay will provide the brand, channel, and product for each partner.
In addition, NewDay will set cookie consent based on the analyticsCookieConsent
parameter value, which can either be 'true' or 'false', and provided in the query string. This allows for analytics and marketing activities such as Google Analytics or Mouseflow to operate.
However, if consent is not provided, NewDay will display a cookie consent banner and request the user to choose their preferences.
Javascript
1https://apply.newdaycards.com/[brand]/[channel]/[product]/prequoted?token=<token>&analyticsCookieConsent=<true|false>"
Once the application handover has been successful, NewDay will handle the application status and display the relevant UI screen, this allows the customer to continue their journey on NewDay's website.
Responses and Statuses
Journey Response
Response Sample
Node + Request
1{
2 success: <false|true>,
3 status: <status>,
4 message: <message>,
5 appId: <applicationId>,
6 customerRef: <customerRef>,
7}
Journey Statuses
Status | Meaning |
---|---|
techError | Unexpected Technical Error |
quotedecline | Applicant declined at check eligibility |
dupeapplication | An application with for the same applicant already exists |
decline | Applicant declined at apply |
adverseBureau | Applicant declined at apply |
affordability | Applicant declined at apply |
otherBureau | Applicant declined at apply |
score | Applicant declined at apply |
refer | Not possible to onboard the applicant, more checks required |
appexpired | The application has expired |
appcomplete | The application has been completed, but boarding failed |
appboarded | The application has been completed and boarded (only successful scenario) |