Connector Architecture

Jump to Section

The GoCardless connector allows banks and financial institutions to start direct debits from other bank accounts. The following aspects are handled:

Register direct debit mandates.
Link existing direct debits to existing customer accounts.
Direct debit processing.

API authentication

At connector level, the Basic authentication method is used for authenticating Mambu API requests. GoCardless uses token-based authentication, therefore an access token with read/write access needs to be created.

Link between Mambu and GoCardless

Before starting a payment request the following link between Mambu and GoCardless entities should be in place:

When a new mandate is started for a Mambu entity, a corresponding GoCardless Customer entity is created. The customer id should be stored at Mambu client level in a dedicated custom field.
Mandate details, such as id and reference, should be stored at Mambu loan or deposit account level custom fields.

After payment processing the GoCardless payment id is stored in Mambu in a dedicated custom field at the repayment or deposit transaction level.

Mambu Process Orchestrator entry points processes

Depending on the Mambu entity involved and the desired action that needs to be executed in Mambu Process Orchestrator (MPO) there are multiple entry points processes.

Entry point process	Description
`01 Subscribe a loan for new DD mandate`	Process used to subscribe a loan for DD payment option. If the loan doesn’t have a mandate linked: - Registers the account owner in GoCardless. - Registers payment account data in GoCardless. - Creates a mandate in GoCardless. - Links GoCardless mandate and the account
`Subscribe a loan for existing DD mandate [with callback, for APIs]`	Wrapper process on top of the MPO process `01 Subscribe a loan for new DD mandate`.
`02 Subscribe a loan for existing DD mandate`	Process used to subscribe existing loan accounts to an existing mandate. Checks mandate status and mandate owner to check that is the same as the account owner.
`Subscribe a loan for existing DD mandate [with callback, for APIs]`	Wrapper process on top of the MPO process `02 Subscribe a loan for existing DD mandate`.
`Create loans DD payment request [for Mambu webhooks]`	Process used to initiate a GoCardless payment request for a loan account.
`Create loans DD payment request [with callback, for API calls]`	Wrapper process on top of MPO process `Create loans DD payment request [for Mambu webhooks]`.
`01 Subscribe a savings account for new DD mandate`	Process used to subscribe a savings account for DD payment option. If the loan doesn’t have a mandate linked: - Registers the account owner in GoCardless. - Registers payment account data in GoCardless. - Creates a mandate in GoCardless. - Links GoCardless mandate and the account
`Subscribe a deposit for a new DD mandate [with callback, for APIs]`	Wrapper process on top of the MPO process `01 Subscribe a savings account for new DD mandate`.
`02 Subscribe a savings for existing DD mandate`	Process used to subscribe existing savings accounts to an existing mandate.
`Subscribe a deposit for existing DD mandate [with callback, for APIs]`	Wrapper process on top of the MPO process `02 Subscribe a savings for existing DD mandate`.
`Create savings DD payment request [for Mambu webhooks]`	Process used to initiate a GoCardless payment request for a deposit account.
`Create savings DD payment request [with callback, for API calls]`	Wrapper process on top of the MPO process `Create savings DD payment request [for Mambu webhooks]`.
`GoCardless callbacks processing endpoint [To be linked with GC]`	GoCardless sends notifications via a webhook whenever the status of a mandate or a payment changes. This process is used as a receiver for the webhook set in GoCardless.

State diagrams

State diagrams are used to hold ,andates and payments states due to the asynchronous and distributed architecture of the connector. The state diagrams are:

Callbacks database stores all the events received for mandate and payment entities from GoCardless.
Events database database stores all the events received from GoCardless in dedicated Set state nodes according to their MPO processing action status: Processed events, Ignored events, and Event processing errors.
Events failed stores all the events with errors from processing.
Payments database stores the payment request initiated in GoCardless: Payments requests, and Failed payments requests.

Business Flows