With this service, the calling apps can KYC a customer's account number or other authorization details like cards or wallets. This service will only return minimal KYC information. Apps will collect the account number they will like to obtain information on and forward it to OnePipe. If authorization details are required by a provider, apps will have to provide this. OnePipe will in turn forward to the provider’s dedicated implementation.
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.
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.
Settlement & fees model
Model | How it works |
---|---|
Invoice | The host client will invoice the calling app periodically for all calls to the endpoint. |
Process flows
Sequence of calls
App calls
/transact
with the right auth detailsProvider responds with
WaitingForOTP
orPendingValidation
as may be requiredApp calls
/transact/validate
to supply OTP if neededProvider responds with any of the completion codes
Successful
orFailed
.To query the status of a transaction, the app can call
/transact/query
Where the provider supports it, the app can call
/transact/reverse
to request a reversal
INTERFACE SPECIFICATION (APP → ONEPIPE)
For details on encryption using the Triple DES Algorithm, read this.
Request (Transact)
{ "request_ref":"{{request_ref}}", "request_type":"lookup_account_min", "auth": { "type": "bank.account | card", "secure": "{{encrypted_secure}}", "auth_provider": "Beeceptor", "route_mode": null }, "transaction": { "mock_mode": "live", "transaction_ref": "{{transaction_ref}}", "transaction_desc": "A random transaction", "transaction_ref_parent": null, "amount": 0, "customer":{ "customer_ref": "{{customer_id}}", "firstname": "Uju", "surname": "Usmanu", "email": "ujuusmanu@gmail.com", "mobile_no": "234802343132" }, "meta":{ "a_key":"a_meta_value_1", "b_key":"a_meta_value_2" }, "details": null } }
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": { "customer_id": "007935125", "account_name": "BOLA SALAMI", "account_number": "1780161243", "last_name": "SALAMI", "first_name": "BOLA", "middle_name": "-", "gender": "Female", "account_currency": "NGN", "dob": "yyyy-MM-dd-HH-mm-ss" } } }
Request (validate with otp)
{ "request_ref":"{{request_ref}}", "request_type":"lookup_account_min", "auth": { "secure": "{{encrypted_otp}}", "auth_provider": "Beeceptor" }, "transaction": { "transaction_ref": "70713093460718" } }
Breakdown of the details object
For this service, the details object will be null.
Possible values for auth.type
card
bank.account
wallet
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 |
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, then respond with WaitingForOTP or PendingValidation. On the OTP validation leg, if user OTP is valid, the provider should retrieve info from the database, then respond with a Successful response.
NB: Data should be erased from the DB upon response.
Dependencies
This service may use the send_otp and validate_otp services behind the scenes to handle the OTP authentication process. Alternatively, it may use the send_sms or send_email services. These services should be invoked by the provider using the API key of the calling app. As such, these services need to be enabled for the calling app as well, otherwise this request would fail.
Add Comment