FAQ
|
awesdf |
||
|---|---|---|
|
If a product is month to month how do we use the “term” property |
||
|
How long is the cookie stored to restore an enrollment session |
||
|
How do I identify residential vs. commercial addresses? |
||
|
Do we need to determine if an enrollment is a Move In or a Switch on the front end? |
||
|
What can be passed for adID or testID parameters when creating an account session |
||
|
If IsAutoPayRequired is true, do we need to set a minimum payment amount? |
||
|
What are the values for Action and Reason properties? |
Block - prevent any forward progress and display message “Blocked for Fraud Prevention: Call <number> for assistance." Redirect - redirect = redirect the browser to the URL in the ‘reason’ property Collect, Verify - display a screen notifying customer of the document verification required. Deposit, Submit |
|
|
How does the Onfido document verification work? |
I am imagining it works like this: When FE receives the ‘verify’ action and the URL, the app will proceed to a ‘Verification’ step, which will briefly explain what is needed and direct them to click a link, opening in a new tab, to complete the verification process on Onfido. When this step loads, it will start listening to the Payless API (via polling or websocket) for the signal that the verification was complete. At the end of the Onfido flow, it can redirect to a page on account.paylesspower.com with a message telling the user that verification is complete and to return to their enrollment. The Payless BE gets the result of the verification from the Onfido web hook. The ‘Verification’ step in the app gets the signal that verification is complete and advances to the next page (or does some other action based on the response from the Payless API). Does this sound right/feasible? I’m not 100% clear if the web hook communication happens between the BE and Onfido or the FE. I think this workflow makes sense though? |
|
|
How do i attribute the enrollment to a 3rd party broker |
||
|
3. What language should we display when a customer fails the identity check? |
||
|
Is the logic for if and where the phone and email Twilio verification checks take place staying the same, or changing? Current logic is: - Prepaid: No email verification. Phone verification happens after Contact Info step - Postpaid*: Email verification happens after Account Details step. Phone verification happens after Contact Info step. |
||
|
5. How should the FE determine which serviceTypeId to send when creating the account session? |
||
|
Okay promo code/agentId issue is fixed. For clarify: “Promo code” is synonymous with agentId. There are three ways it can be set: 1. Visiting /enroll/<code> will verify the code, and If valid will set an agentReference cookie with teh agentId and return the agentId, userId and phoneNumber of the agent to the view. 2. Visiting /enroll with an agentReference cookie will verify the id, and if valid return that same information to the view. 3. If no agent information is passed to the view, user can enter one into the “promo code” field. It will do the same thing: verify the code and then store that userId, agentId, and phoneNumber. If an agentID is set through either of those methods, it will appear in the masthead next to “Promo: “. agentId is sent to the API when the customer session is created in the agentId parameter. If none is set from the above methods, it will use the default value of 184225, but this default agent is not shown in the UI. |
||
|
How does the fraud funnel work for customers who clear the session cookie? |
||
|
How does the fraud funnel work for customers who use incognito mode in their browser? |