Dispute Application

The Silverflow dispute solution can be interacted with in two different ways:

The DRA is a GUI which is fully integrated with the API that can be accessed through an iFrame. Both the API and the DRA can be used in parallel.

The Silverflow Dispute Response Application allows merchants to interact with their disputes through a web-based interface. This application can be easily embedded in an existing (merchant) portal.The DRA is contained within an HTML iframe to enforce strong and clear security boundaries between the application and the containing application and reduce risk of cross-interference and incompatibilities. It consists of a ‘static’ HTML file hosted by Silverflow which loads a Javascript application. This application interacts with the Silverflow Disputes API for a particular merchant and renders a web-based user interface. The following diagram illustrates the interaction between the merchant's browser, the iframe, the portal and the Silverflow API:

As the application itself does not authenticate the merchant that is logged in to the portal. It relies on the ‘embedding page’ to supply a Silverflow-issued JWT bearer token (see Create Bearer Token) for the authenticated merchant which the application will use in the interaction with the Silverflow Disputes API.This token must be obtained by calling an endpoint on the Silverflow API that creates a (temporary) JWT token for that particular merchant. Calling this endpoint is the responsibility of the embedding page.The iframe needs to interact with the embedding page to request and receive the JWT token. To facilitate this interaction the application will send a message to the embedding page through the postMessage function which is specifically designed to securely exchange messages between windows. This message will contain the sf:disputes:request-merchant-token text and should be picked up (listened for) by the embedding page.After confirming that the message originated from the application the embedding page should respond to this message with a fresh JWT token for the merchant by invoking the postMessage function on the iframe of the application. This message should contain the token and the request sf:disputes:merchant-token. This will complete the secure token exchange for the lifetime of the JWT token.When the token has expired the application will call the embedding page again, requesting a fresh token.

The application can be positioned anywhere on the page of the merchant portal. Note that the interface is responsive but will display the functionality more efficiently if it covers the full width of the screen.

The styling of the application is defined by CSS. Silverflow will have the application match the look and feel of the your portal. At any time, limited to a reasonable frequency, you can supply an improved version of the CSS stylesheet, which Silverflow will then include in your version of the application at the earliest convenience. When you have supplied a modified version of the CSS stylesheet it is your responsibility to ensure the correct rendering of the application in the browsers that your portal supports.Note that over time the functionality of the application may change and adjustments to the stylesheet need to be made. In this case Silverflow will make the required changes to the stylesheet to ensure new versions of the application are rendered correctly. When you want to make adjustments to the stylesheet it should always use the latest version.

The application contains a Content Security Policy (CSP Level 2 - W3C Recommendation) that restricts where it can be embedded. You should provide the host names so that Silverflow can include them in the policy.

The following section illustrates how the application could be embedded in an existing web page. When targeting our Sandbox environment the following changes must be made:

The application will open a specific dispute page directly if the parameter disputeKey is appended to the iframe src attribute.

If you want to use the direct dispute link you should keep in mind that reloading the browser window will load the dispute page again if it finds a disputeKey in the iframe's src attribute. To prevent this behaviour you have to make sure the disputeKey is only passed to the iframe once. In the following example this is accomplished by using a hash and deleting it after the iframe has been loaded.