Bango uses cookies to give you the best website experience. By using this website you agree to let Bango use cookies. More info
OK
Bango Developer
  1. Bango Resale
  2. Architectural overview

Bango Resale API architecture

An abstraction layer between resellers and merchants

The Bango Platform provides an abstraction layer, exposed publicly as the Bango Resale API, between resellers (which bundle or resell products and services from third parties along with their own) and merchants (which want to allow others to bundle or resell their products and services). In Bango terms, using the Bango Resale API means you're acting as a reseller. (You might also use the Bango Payment API, which makes you a first-party merchant too.)

Third-party merchant stores generally all present different APIs. This makes it hard for you to resell or bundle products and services from multiple merchants: for each new merchant, you must write custom integration code. The Bango Resale API provides a consistent interface so you integrate only once. After integration, you can begin offering services from merchants plugged in to the Bango Platform (subject to agreement). Your systems are insulated from any changes merchants might make to their APIs, and you benefit from the Bango reporting and analysis tools.

Bango Resale API block diagram

The Bango Resale API is RESTful, uses UTF-8 JSON to encode parameters and response values, and includes features to help you test your integration. (Make sure you understand the connectivity requirements for accessing the Bango Platform.)

The Bango Resale API supports both synchronous activation of services (where no user interaction is required) and asynchronous activation (where user interaction is required, such as following a merchant-supplied sign-up link). In the API, a user's ability to access a merchant's service is represented as an abstract "entitlement" record which is always in one of several states. API calls can update the record and modify the state to reflect changes in a user's entitlement to access the service.

Here's a diagram showing an asynchronous activation.

Sequence diagram: Send user to sign-up URL

In this example, the merchant requires a user to sign up before the service is activated. This means your initial request to create an entitlement returns an entitlement record with status PENDING, along with a request to send the user to a particular URL supplied by the merchant. Your initial request should also include a URL under your control: the Bango Platform uses this to notify you of subsequent changes to the entitlement. When the merchant confirms to the Bango Platform that the user has signed up, the Bango Platform sends an updated entitlement record (with status ACTIVE) to the notification URL.

Copyright © 2000–2019 Bango.net Limited