...

With this service, the calling apps can do a transfer to a destination account number from a given source. If authorisation details are required by a provider, apps will have to provide this. OnePipe will in turn forward to the provider’s dedicated implementation.

Commercial model

The provider should have it's own way of debiting the preconfigured account (which will be passed either in beneficiary info or extras) then execute the transfer. Provider needs to send a share of income to the settlement account at the host; which will then be shared with OnePipe, host and ISO. Parties that share the fees are:

1. OnePipe

2. Host client

3. ISO

Settlement & fees model

...

Model

...

How it works

...

Amount or Commission

...

Provider sends a share of income to the settlement account at the host; which will then be shared with OnePipe, host and ISO.

Special configuration notes

• OTP override: All providers of this service should implement OTP, but support the configuration of otp_override such that based on this configuration, they could be instructed to bypass the OTP requirement for an app.

• SMS handler: All providers that need to do OTP validation can use the Send SMS and Send Email services on OnePipe to send their OTP.

Process flows

Sequence of calls

1. App calls /transact with the right auth details

2. Provider responds with WaitingForOTP or PendingValidation as may be required

3. App calls /transact/validate to supply OTP if needed

4. Provider responds with any of the completion codes Successful or Failed.

5. To query the status of a transaction, the app can call /transact/query

6. Where the provider supports it, the app can call /transact/reverse to request a reversal

There are two scenarios to this:

Scenario 1: Provider does 2FA on transaction

...

Scenario 2: Provider MS does 2FA on transaction

...