Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

With this service, the calling apps can do a transfer to a destination account number from a pre-configured account of the app. 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. This is a service that is useful for when a business wants to debit their own account and credit any destination account.

Before you proceed: Please read this.

Commercial model

The provider should have it's own way of debiting the pre-configured 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.

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

INTERFACE SPECIFICATION (APP → ONEPIPE)

For details on encryption using the Triple DES Algorithm, read this.

Request (Transact)

{
  "request_ref":"{{request_ref}}", 
  "request_type":"disburse",
  "auth": {
    "type": null, 
    "secure": null,
    "auth_provider": "Beeceptor",
    "route_mode": null
  },
  "transaction": {
    "mock_mode": "live", 
    "transaction_ref": "{{transaction_ref}}", 
    "transaction_desc": "A random transaction", 
    "transaction_ref_parent": null, 
    "amount": 1000,
    "customer":{
    	"customer_ref": "{{customer_id}}",
    	"firstname": "Uju",
  		"surname": "Usmanu",
    	"email": "ujuusmanu@gmail.com",
    	"mobile_no": "234802343132"
    },
    "meta":{
    	"a_key":"a_meta_value_1",
    	"another_key":"a_meta_value_2"
    },
    "details": {
    	"destination_account":"2363262632",
        "destination_bank_code":"011",
    	"otp_override": true
    }
  }
}

Response (when otp_override = false)

{
    "status": "WaitingForOTP",
    "message": "Please enter the OTP sent to 2348022****08",
    "data": {
        "provider_response_code": "900T0",
        "provider": "Beeceptor",
        "errors": null,
        "error": null,
        "provider_response": null
    }
}

Response (when otp_override = true)

{
    "status": "Successful",
    "message": "Transaction processed successfully",
    "data": {
        "provider_response_code": "00",
        "provider": "Beeceptor",
        "errors": null,
        "error": null,
        "provider_response": {
            "reference": "000022200225154318222333334432",
            "payment_id": "136FTTP200590171",
            "destination_institution_code": "000016",
            "beneficiary_account_name": "JOHN DOE JAMES",
            "beneficiary_account_number": "3056433222",
            "beneficiary_kyc_level": "3",
            "originator_account_name": "James Jane",
            "originator_account_number": "0001131256",
            "originator_kyc_level": "1",
            "narration": "My narration",
            "transaction_final_amount": 1000
        }
    }
}

Request (validate with otp)

{
  "request_ref":"{{request_ref}}", 
  "request_type":"transfer_funds",
	"auth": {
        "secure": "{{encrypted_otp}}",
        "auth_provider": "Beeceptor" 
    },
    "transaction": {
        "transaction_ref": "70713093460718"
    }
}

Breakdown of the details object

For this service, the details object will have the following:

Field

Type

Requirement

Description

destination_account_number

string

compulsory

Destination account to send funds to

destination_bank_code

string

compulsory

Destination institution code

otp_override

boolean

optional

Defaults to true. If set to false, request will be validated by OTP.

Possible status response codes

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

Status

Meaning

Successful

Standard success code

Failed

Standard failure code

WaitingForOTP

To signify that this provider has requested an OTP from the customer and it should be supplied.

PendingValidation

To signify that this provider needs some extra information to be provided. The response.message will contain the prompt.

INTERFACE SPECIFICATION (ONEPIPE → PROVIDER MICRO SERVICE)

Read this closely.

Special notes for OTP override

Whenever a request is to be validated by OTP, the provider microservice should first call the provider, store response info in the database, send an OTP to the phone number attached to the source of fund, then respond with WaitingForOTP.
On the OTP validation phase, if user OTP is valid, provider should retrieve info from the database, then respond with a Successful response.
NB: Data should be erased from the DB.

 

  • No labels