Transaction Notification

With this service, app developers will expose a webhook url, that will receive a POST message from OnePipe upon a credit or debit activity on an account that they have access to. This notification will be triggered by the provider, directed to OnePipe which will in turn transform the message into the payload that the app developer’s webhook is expecting and able to process. The ideal use case for this is in offline payments.

Before you proceed: Please read this.

Commercial model

At agreed settlement cycles, the host will debit the configured beneficiary account of the app for the use of this API and share that fee with all participants. Fees will be determined by the provider. A credit notification also implies that a provider already has the monies that belong to the app developer with them and probably need to execute settlement to them at agreed cycles outside of OnePipe.

Special configuration notes

Providers need to support as much configuration as is possible rather that enforce strict payload content.

Settlement & fees model

At the moment, this service only supports one model.

Model

How it works

Model

How it works

Invoice

The client will invoice the calling app periodically for all calls to the endpoint.

Process flows

Sequence of calls

  1. Setup

    1. All apps that want this services will configure their webhook on OnePipe

    2. A custom webhook designed specifically for the provider is also implemented on OnePipe

    3. Customer presents payments details at a provider’s channel

  2. [optional] Validation

    1. [optional] Provider makes a call to its webhook on OnePipe to pull details of the payment or customer

    2. The provider webhook makes a transaction_info call to a OnePipe listener

    3. [optional] OnePipe may forward this call above to the app’s webhook in the the form of a transaction_info request

  3. Completion

    1. Provider process the transaction offline

    2. Provider makes a call to its webhook on OnePipe to record the transaction

    3. The provider webhook makes a payment_fulfillment call to a OnePipe listener if this call matches a prior transaction_info. If not, it makes a transaction_notification call instead.

    4. OnePipe will forward this call above to the app’s webhook in the the form of a transaction_notification request

Interface specification - (Provider Service → OnePipe Listener)

Request (transaction_info)

...

Response (transaction_info)

...

Request (payment_fulfilment)

...

Response (payment_fulfilment)

Request (transaction_notification)

Response (transaction_notification)

 

 

Interface specification - (OnePipe Listener → App Webhook)

Request (transaction_info)

Response (transaction_info)

Request (payment_fulfilment)

Response (payment_fulfilment)

Request (transaction_notification)

Response (transaction_notification)

 

Headers to expect (OnePipe Listener → App Webhook)

Type

Description

Type

Description

 

 

 

 

 

 

Possible response codes (OnePipe Listener → Provider Service)

For this service, these are the possible responses a provider service can receive

Response code

Meaning

Response code

Meaning

 

 

 

 

 

 

 

 

Special notes for providers

Unlike other services where the app calls OnePipe, in this case, the Provid should be seen as a standard payments service. All providers are required to execute settlement per agreed contracts to the account designated by the client bank.

Â