Dispute Application

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

The DRA is a GUI fully integrated with the API, which 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 the 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:

The application does not authenticate the merchant 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 the application will use to interact 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, specifically designed to exchange messages between windows securely. 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 application's iframe. 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 expires, the application will call the embedding page again, requesting a fresh token.

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

CSS defines the styling of the application. Silverflow will have the application match the look and feel of your portal. At any time, limited to a reasonable frequency, you can supply an improved version of the CSS stylesheet, which Silverflow will include in your application version at your earliest convenience. When you have provided a modified version of the CSS stylesheet, you are responsible for ensuring the application is correctly rendered in the browsers that your portal supports. Note that the application's functionality may change over time, and adjustments to the stylesheet need to be made. In this case, Silverflow will make the required changes to the stylesheet to ensure that new versions of the application are rendered correctly. When you want to adjust the stylesheet, 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 Silverflow can include them in the policy.

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

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

If you want to use the direct dispute link, remember 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'll need to ensure 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.