Let's start. You see relevant pages grouped under categories on the left: "Get started", "Embed solution", and so on (see "1s" in the following figure). And you need to read only two pages to get the big picture of who we are, what our services are, and the details of our services: Introduction to BridgerPay and Solution map ("2s"). All the other descriptions are optional, and you should get acquainted with them only if you've decided to proceed with us and chosen a particular scheme for integrating.
The pages under Get started provide reference information that you are supposed to consult from time to time when integrating or testing our solutions, or getting stuck with some terms or concepts.
Reporting contains different pieces of information used on a regular basis to make sure that all the payment processes work as expected and no transaction has been lost: most critical data statuses passing through the BridgerPay system, notifications generated in response to changes to some of these statuses, alternatives to notifications, etc.
Embed solution comprises the descriptions of two schemes for integrating our Cashier widget. Depending on your business choice, you'll need to study only one. The Overview will help you see the big picture of the Cashier workflow, though.
Embed integration lists various ways of how BridgerPay can be integrated with your system. You need only look through them to get the idea, choose the most suitable for you, and read the page more carefully.
The other categories are devoted to API. Each of them includes one or more related pages describing API methods: "Authorization", "Cashier initialization", etc. If an API integration scheme is complicated and engage various methods, the sequence and interaction of the involved methods are described on a separate page grouped under an appropriate category: e.g. the Overview of Payouts.
Additionally, pages providing technical knowledge—Cashier integration schemes and API methods—follow a pattern to standardize their descriptions and, thus, help you find the necessary piece of information more easily. A code or request example is at the top (see "1" in the following figure) so that you can use it to get started with the scheme or method at once. Later, two tabs or sets of two tabs provide the detailed descriptions of the input parameters ("2") and the way these parameters affect the front-end part (for Embed) or the content of a possible response (for API, "3"). At the bottom, there might be other request examples showing how different input parameters are processed ("4"), e.g. another combination of payment method and PSP for "Create payout".