API -
This link is up to date and ultimately should be used for anything API related for Case Intake.
https://confluence.quavo.com/qfd-knowledgebase/public/case-intake-api-overview-49849026.html
Widget Overview
QFD provides two widgets as part of the product:
Intake - This widget allows an accountholder to dispute a transaction by using a guided wizard approach that allows them to identify transactions, the reason for the dispute, provide documentation, contact details, etc..
Case Status - This widget shows the history of any disputes filed previously, open or not. Each dispute contains details about the progress of the investigation, whether credit is issued, when the process will be completed, if documents need to be provided, etc.. In addition to providing information, the user can select from various actions to take, such as providing a note, withdrawing the case or submitting documents.
Overall Flow
Accountholder logs into client online banking solution. This can be with any type of device, form factor, etc.. but the assumption is that they are using a modern browser (IE11+, Chrome, FireFox, Edge). This can also include a native app with embedded webview.
The user should be able to complete two actions at applicable points in online banking:
Intake can occur at a customer+account+transaction level, or a customer+account level. An example of the former would be a "dispute this transaction" link on the statement view for each transaction. The latter, a "dispute a transaction" link on the statement view or at the account level
Case status occurs at a customer or customer+account level. Usually this is a link available to "check status of an existing dispute". Generally an accountholder would know they have an existing dispute, so it can always show and would have no content if there are no active disputes. Status can also be checked for historical purposes as a record of already filed disputes
Upon selecting one of the widget actions, a server side RESTful request is made to the QFD implementation:
Quavo will provide you with an OAuth 2.0 client credentials endpoint for authentication, which includes an application identifier and client secret. This secret should not be stored in any client side javascript, code or configuration.
Upon receiving valid client credentials, a call can be made to the URL request RESTful service endpoint
The URL request service will accept certain parameters and return a URL
With the URL returned from the service, the subsequent page should render a page with an iframe with the location as the returned URL. For clarity, it is a client side request from the accountholder's browser that interacts with QFD for widget content. For an app with webview, the URL can also be used as the sole content of the page.
App designs should always remove from memory the webview and allow any previously associated cookies to expire to rendering the page from the URL. In some cases, if a user navigates away from the app and comes back later, we have seen session data retain the browser session and authentication fails. Upon initial authentication, a cookie is issued which expires in the past. For browser based access, this means that upon closing the window, the cookie is destroyed and reauthentication occurs next time. For apps, this same behavior needs to be reproduced. If this is not possible, workarounds are possible
URL Service Request Parameters
CaseType - This will always be DisputeTransaction
Action - This should be set to Create for the intake widget and Status for the status widget
Component1Name - This should represent what the first component is, which is typically an identifier for a customer or member. Reasonable values for this might be "CustomerId", "MemberId", "SSN", etc.
Component1 - This typically is an identifier for the accountholder themselves. This may be a customer id, member id, etc.. it should uniquely identify a human if possible
Component2Name - This should represent what the second component is, which is typically an identifier for an account, share or card. Reasonable values for this might be "AccountNumber", "ShareId", "LoanId", "AccountId", "CardId", "CardNumber", etc.. for the status widget, depending on where it is embedded, this parameter may be omitted.
Component2 - This should represent the account identifier used for the widget. This may be an account number or share id or card number, etc.. for the status widget, depending on where it is embedded, this parameter may be omitted.
Component3Name - tbd if needed. This should represent what the third component is, ex: a unique identifier for a transaction. This parameter is only used for the intake widget. Reasonable values for this might be "TransactionSequenceNumber", "TransactionARN", "TransactionPostDateTime", etc.
Component3 - tbd if needed. Ex: this could be an identifier for a particular transaction. This identifier needs to be unique to a transaction and tie back to one provided to QFD by the core banking integration. Sequence numbers, timestamps, etc.. are typically used here.. This parameter is only used for the intake widget.
Component4Name - tbd if needed
Component4 - tbd if needed
Sample URL call request (Intake)
{
"CaseType": "DisputeTransaction",
"Action": "Create",
"Component1Name": "CustomerId",
"Component1": "123456789",
"Component2Name": "ShareId",
"Component2": "05",
"Component3Name": "TransactionSequenceNumber",
"Compoment3": "182"
}
|
Sample URL call request (Status)
{
"CaseType": "DisputeTransaction",
"Action": "Status",
"Component1Name": "CustomerId",
"Component1": "123456789",
}
|
Sample URL call response
Sample Status Widgets
