CFWeb Architecture

The CFWeb architecture includes a Merchant (service layer) and a Customer (end-user). The CFWeb architecture is deployed to support online use cases and allows you to generate a request ID and URL for the Customers Verify Request experience. The Verify Request API initiates the process for the customer to begin submitting documents. The web service layer curates the JSON responses sent to the Merchant (Enterprise Customer). The process is illustrated in the diagram below:

Certificate-based Mutual Authentication

Requests between Merchant Server Application and Hosted Server Application are authorized using a client-side certificate. This certificate is received during the initial HTTPS handshake between the Hosted Server Application (acting as a server) and Merchant Server Application (acting as a client).

Once this certificate is received on the server-side, the certificate is validated, and the Merchant’s identity is established. If the certificate validity cannot be established, the request is denied, and HTTP Status FORBIDDEN (Status Code 403) is returned.

CFWeb Client Text String Localization

If you require localized text strings to match the end user’s browser language of choice, the CFWeb Client supports language packs. This browser will automatically use the proper language pack if the language is available on the CFWeb server.

When CFWeb Client is used for localization, then the security certificates will continue to function. If you prefer to build your own web client using our WebSDK, then the certificates will need to be exchanged and validated. This is a bigger work item than simply using our CFWeb Client with the language pack added to the CFWeb Server and does require assistance from our team.