Rishabh Mishra /TxB.

/IBANVBBSR

From: Rishabh Mishra /rxB./IBAN IVBBSR

Sent: Tuesday, March 2?,20?2 6:20 ?M
To: Sangram Behera /PS_DEPT/IBANVBBSR; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]
Cc: Verender Singh /PS-DEPT/IBANVKOL; Pinak Pati AxB./IBANVBBSR; Udit Khanna
/PS-DEPT/IBAN VBLR; Santanu Basak /PS-DEPT/IBANK/KOL; Shanti Das
/TASC&GBG_D/IBANVBHUBANESHWAR; ArNAb MiStry /EXT/TXB/IBANVWOTK
Location; [email protected]; Mohammad Manoweruddin
/DP-DE PTII BAN K/KO LKATA
Subject: RE: Bhubaneswar Development Authority ll composite API -lmplementation Documents
Attachments: Composite API _ Errorcodes_ l.16.xlsx; Composite AP|_Document v1.'l6.pdf; CAS On-
boarding Forl.pdf; New Client onboarding_Volume Data.docx

Dear Team,

Kindly find the below documents for integration and UAT set up, as discussed:
o On boarding fornr (attached)
o Volume data (attached)
o SSL certificate
o 4096 Bit public key for encryption-decryption
o IP to be rvhitelisted (UAT and Production)
. Call back URL
Please sign up in API porta I and share user id. Li nk : https://developcriprsrbanl(xo!0

Comrnercial Details:
Transaction charges will be as tbllows

Mode olPavment Transaction Value(Rs) Rate (Rs. -per transaction)*

.:r -
[ ]PI and II\4PS '. -
[-ri';itlran INR 1.000 1.5
'i rl, Il. l'. a<ll INR 1,000 - rNR i,'
2.5
25,000
Above INR Rs. 25,000 6.5
*+Applicable Taxes.

Rishabh Mlshra
Accounts Manager- Trqnsactlon Banklng
Mob:9938Q72E15
Mail: (!lha 6h. m@ iciciba n l(.cgm
AlClCl Bank
J 7 Transaction Banking

From: Sangram Behera /PS_OEPT/IBANK/BBSR <[email protected]>

Sent: Tuesday, March 22, 2OZZ 5:42 ?M
To: pra kash.chandra @highbartech.com; sandeep.parida @highbartech.com; sabina. [email protected];
1
 OrcrrrBank

COMPOSITE PAY API

Documentation
 Orcrct arrx

Document Revisiori
Datdi :
I
Veistob!!l DescriDtion
'0.1:
lnitiat Draft
17-Jth-2019 0.7 CIB API added
'18.$ n-2019 0.3 Changed Apt process ftow Tr{lt._
01-.lut-2019 0.4 lnctusion of each ftow request- response packet.
*'' :' '
1oiiul';201 9 0.5 UPI Fietds Description updated.
17 -Jul-7019 0.6 UPI fietds addition
25-Jut-2019 0.7 Error Codes Addition- UPl, IMPS, NEFT
30-Jut-2019 0.8 Cur[ added
01 -Aug-2019 0.9 UPI request packet correction
07-Aug-7O19 0.1 0 IMPS API spec update
08-Aug-2019 't.01 IMPS paytoad changes

12-Aug-2019 1.02 IMPS Tran lnquiry API Added

1 6-Sep-2019 1.03 Addition Beneficiary Registration API
01-Oct-2019 1.04 Addition of bene reg. codes & change in UPI request packet
04-Nov-2019 1.05 Revision of error codes
16-Dec-2019 1.06 lnclusion of RTGS API

31-Dec-20'19 1.07 Inclusion of Beneficiary APls for UPI

02-Mar-2020 1.08 Revision of Error codes & Documentation
08-Mar-2020 1.09 Revision of FAQs
12-Mar-7070 1.10 Updating UPI request packet & introductron part
04-June-2020 1.11 Addition of Addendum - List of changes incorporated in vl .1 1

06-Aug-2020 1.17 DaiLy transaction MIS

I

26-Nov-2020 1 .13 IMPS 360 APl, CIB API under hybrid encryption and VPATag addition
12-Dec-2020 1.14 New APIGEE lPs added in composite API

30-Apr-2021 1.15 Status and 360 APIs integrated into composite status API
08-Sep-2021 1.16 IMPS recon API tranref number based search
 flrcrct aunx
' Contents

Sr. No. Description Page no

1 INTRODUCTION 4
l.Brief 4
2.Structure of payments 4
3.Technical Pre-requisite required from client's end 5
4. Debits allowed for Nodal Account holding clients 5
5. Daily transaction MIS 6
2 APIDETAILS 7
1. Composite API 7
2. Composite status - UPI 19
3. Composite status - IMPS 22
5. Status check - NEFT & RTGS 27
6. NEFT lncremental Status API 29
7. Beneficiary Registration API 31
8. CIB Registration API 33
3 CURL COMMAND 35
4 SECURITY 35
5 ENCRYPTION.DECRYPTION PROCESS 35
6 FAQs 39
7 Appendix & Erratum 38
 fii,",", aunu

1. INTRODUCTION:

. .
t. nil=er: ]-...
'1$:'
:

-.':t-
tn'tciilay's digitat wortd, large base of E-commerce companies and ea'yh6nt Gatbway Aggregators
companies are moving towardsAPl based payments and collection solutions and drifting away from
the existing payment solutions which have a manual intervention or muttipte hops in processing of
the payments to the beneficiaries

ln context to this document, we are introducing the "Composite pay APl" that witt cater to any of
the payout types payments. The umbrella of composite API witt atso include the status check API
and beneficiary services APls for Nodat account hotding merchants. Through this the customer wi[[
have atl the payment modes in the API with them and wouldn't have to go into further iterations
of integration with the Bank. Currently, IMPS, NEFT and UPI are a part of this APl.

The API is designed in such a manner that it can accommodate multiple payment modes, has a
provision of prioritizing a specific payment mode and the immediate payment modes tike IMPS and
UPI can atso have a fattback option of NEFT or other payment modes once introduced. The ctient
can atso choose to use a[[ or any one mode of payment. The Composite Pay API is hosted in the API
Gateway of lClCl Bank. APIGW witt route any request of Composite Pay API to the respective system
of the payment mode depending on the priorities set in the payment request.

ln the ERP Banking context, these APls witl be directty integrated into the ERP of the ctient and
the ctient can directty carry out the transactions from the ERP. The transaction status will be fed
back into the ERP as response to the fired API (more detaits given betow). The entire maker-
checker leg is at the customer's end without any bank's ptatform being involved in the process.

2. Structure of pavments:

2.1 CIB Reqistration':

This is a mandatory one-time registration API that is required to access the Beneficiary
Registration & Vatidation APl, NEFT and RTGS payment mode APls. CIB (Corporate lnternet
Banking) is the internal data-base in lClCl Bank for composite pay API and hence, for
processing these APls credentiats are required to be created for the ctient in the CIB
database.

2.2 Beneficiary Registration":

This is the first step for merchants hotding the Nodal account. After CIB registration API is
fired, this API is required to be fired which shatl register beneficiaries on the fly to the CIB
database.

2. 2 Beneficiarv Validation*':

The bene validation service is a part of composite pay API and is structured in such a way
that when the Composite Pay API is hit by the ctient, at the bank's end the bene vatidation
service wit[ be called first by APIGW which wit[ check if the bene is registered in the CIB
 O,",",
database. lf the vatidation is successfut, the transaction [eg is catted which
orr
processes the
transaction basis the payment mode. lf the validation faits, the transaction is dectined. The
ctient is shown an appropriate error code as response that the beneficiary is not registered
and the transaction is declined. Ptease note, this beneficiary validation teg witt only be
enabted for the Nodal account hotding merchants only.

'ClB registrotion API is required for clients who wont to occess NEFI, RTGS or beneficiory
registrotion APl.
..Beneficiary Registration &, Validotion is mondatory
for Nodol account holding merchants. Pleose
refer the section '4, Debits allowed for Nodal account holding clients'in this section below.

2.3 Pavments:

The composite API witt first hit the APIGW system from clients ERP system. Based on the
priority set by the client, APIGW will route the transaction request to the respective
payment mode systems.

2.4 Reverse Feed:

The transaction status witl be shared as response within the same API catl for IMPS and UPI
modes whereas for NEFT and RTGS' mode actua[ status of the transactions witl be availabte
once the transaction batch gets processed. After that, the client is required to fire the
status check API which witl be provided to the ctient to fetch the transaction status. These
statuses essentiatty get captured back again in the ERP of the ctient against the respective
transaction.

Please note, even though UPI and IMPS are real-time payment modes, but we recommend
foltowing timetine to our ctients:

For UPl, the final, status of the transaction witl be avaitable between 180 secs and T+2 days
of initiating the transaction

For IMPS, the final status of the transaction wi[[ be avaitable between 180 secs of initiating
the transaction.

l.The exact timeline is subjective to purying activity ot our end, Hence, it is recommended
to check with lClCl Bonk teom before taking any oction on back dated transaction. ldeolly)

2.5 Status Check:

lf the ctient doesn't receive the response of a transaction, they can use the Composite
Status Check API of the respective payment mode X-priority to fetch it. Ptease note, until
the status is confirmed, the ctient is not supposed to change the reference number and re-
initiate the transaction.

3. Technical Pre-requisite required from client's end"":

 flrcrct ernk
1. lP Address: The lP needs to be whitelis ted at our end to ensure the security.

2. 4096 Bits Public Kev Certificate: Composite API witt fotlow encryption and decryption
.mechanism to send and receive request & response from ctient's end. Every certificate fite
witt h-ave two compbnents, i.e. Puttic Key certificate e nrivaier<ey-c"rtiti.ut". pubic Key
' Certificates are useil to encrypt and Private key certificates are usdd to decrypt.
' The client witt use tcict aank;i pubic key certificate i.i tha il6;;i
request. rcrcr
Bank witt decrypt ttiB payment request using our private ""i.lpi
key tbrtlfjcaie and then process
the transaction acc6rdingty as per the payment mode preferrbd. Aftbr the request has been
,, .'processed, lClCl Bank witt encrypt the response using ctient's pubtlc key certificate and post
" it back. Ctient witt use their corresponding private key certificat'e td decrypt the response
received.

These certificate files are available with third party vendors. A setf-signed certificare for UAT
is acceptable, but for live environments a CA signed one is mandatory.

...Please note, we require the technical pre-requisites lists in both UAT ond Production
environment.

4. Debits allowed for Nodal Account holdin g clients:

There are three types of debits atlowed on nodal account that is:

'l . Refunds/Cashback
2. Vendor payout
3. Commission

Beneficiary Registration and Validation is a mandatory API when the ctient wants to use the Nodat
account for Vendor payouts onty. The ftow witl be such that the client witt first fire the Beneficiary
Registration API and then inctude the registered beneficiary details in the composite API request
packet and then subsequentty fire the composite APl. Composite APl for Nodat account merchants
is structured in such way that they shatt first vatidate the beneficiary before processing the
payment request.

5. Daity transaction MIS:

Daily transaction MIS witt be made avaitabte on the API devetoper portal
(https: / /devetoper.icicibank.com). Client is required to register on the API devetoper portat and
share the User lD with business team. They witt be abte to downtoad day-wise transaction MIS for
last 15 days.
Path: Home Page > Account > MIS Downtoad
Ctients with muttiple accounts or merchant lDs can choose to receive a consolidated MIS on one
single User lD or multiple MIS on muttipte User lD.
 flrcrct ernk
2. API DETAILS
1. Composite Payment API

1.1 Description: This API witt be used to make payment inctuding priority order to identify
and carry out the three types of payment options i.e., UPl, IMPS and NEFT.

'l .2 Flow Diaqram:

Composite API Flow

API GATEWAY

Merahan!Client Banotlciary clB

Regiiarrlion

Bane Ro,
API g St6tl./s check

Belretici.ry
regrstration cla
Slatus check

API crB

lderdtt thg paymenl mod6

UPI
and transro.m Requ6tcd
Pecket acco.dury

...F
!
Eni
Occrsron mat alq
Dy llag
NEFT

RTGS

ll succosg

s{racoss respotis€
pe€tel
 flrcrct e"r*
1.3 API Endpoint:

UAT: https: / /apibankingonesandbox.icicibank.com/api/v1 /composite-payment

LIVE: httos: / /aDibankinqone.icicibank.com/api/vl /comoosite-pavment

Nodal Live: httos: / /aoibankineone. icicibank. com/ api /v2lcomoosite- pavment

1.4 lnput Headers

x-priority:- wi[[ come in request headers along with apikey.

1 .5 lnput Parameters:

Type
Mandatory
(Y-Yes, Provided
Name (max. Description N-No, by lClC
char. O-Optional
Limit) &c- (Y/N)
Conditional)
o
API Header
Priority of Apj sequencing eg: -

1000 for UPI (1 ); lMPs (0); NEFT (0); RTGS (0)

x-priority String 0'100for LJPI (0); IMPS (1 ); NEFT (0); RTGS (0) Y N

1320 for UPI (1 ); IMPS (3); NEFT (2); RTGS (0)

0001 for UPI (0); IMPS (0); NEFT (0); RTGS (1 )
UPI
Unique device Token. Token shoutd be unique
for per channet-user.

The channets which are unabte to poputate the

device-id String (255) device lD need to send mobile number as the Y
vatue in this parameter. UPI switch will not be
vatidating the device lD. lt witt just be
forwarded to NPCI as it is a requirement.

mobite String(10) Mobite Number of the user Y Y

The code for the source application from which

channet-code String(15) Y
the transaction witt be initiated.

l0 of the profite returned in the response of the

profite-id String(10) 'register mobite/store-acc-detaits'APl. This witt Y
uniquely identify the user's profite.

This witt be a txn-id generated by the Mobite

APP. The vatue shoutd be a input to the'txn-id'
in the tibrary. This seq-no shoutd be generated
seq-no String(35 ) using java. utit. UU lD ctass. Y N

This shoutd start with'lCl'and should not have

any special characters.

account-number Number(35) Account Number C N

 0,",", oru
D=Use defautt account for transaction
use-default-acc Char(1) Y Y
N=Use account No and IFSC provided in request
for the transaction.

account-type String(20) Account type of the mapped account

Alias name with which the payee can be
payee-va String(255) N
identified by his registered entity.
payer-va
Atias name with which the payer can be
String(255) Y N
identified by his registered entity.
Amount to be cotlected. (ln Rupees, lnteger
amount Number(14) vatue with 2 decimat) N
E.g. : 200.00 / 300.12

pre-approved Char(1) A=Pre-approved, M=MPIN required, P=for M2P Y

Ftag 'D' witt set this account as defautt debit

account; Flag 'N', witt not set this as defautt
account;
defautt-debit Char(1) When use-defautt-acc has vatue 'D'then this Y
vatue should be 'N';
When this vatue is 'D' then entered account no.
witt be set as defautt;
Ftag'D'witt set this account as defautt debit
account; Ftag'N'witl not set this as default
account;
defautt-credit Char(1) When use-defautt-acc has vatue'D'then this
value should be 'N';
When this value is 'D'then entered account no.
witt be set as defautt;

Currency code for the transaction; if not passed

currency String(3 )
defautt vatue ofINR witt be considered
o

lf 'merchantToPersonPay' then push payment

from merchant to customer's VPA witt be
initiated;

lf'payRequest' then pay to VA witt be initiated;

txn-type String(50)
lf 'payMerchantRequest' then pay to merchant
witt be initiated;
lf 'paytoctobat' then gtobal transaction wit[ be
initiated;

remarks String(50) Remarks entered by the payer for his reference. Y N

mcc Number(4) Merchant Category code

For merchant transactions, merchant type
merchant-type String(50) Y Y
shoutd be 'ENTITY'
Corporate lD (mandatory onty for Nodat
corplD String c Y
account)
SMS Corporate User (mandatory onty for Nodal
userlD String c
account)
Aggregator lD (mandatory onty for Nodal
aggrlD String C Y
account)
 fi,crct arno
URN Number (mandatory onty for Nodat
urn String c N
account)
global-address-
String (20) MOBILEM'IID/ACCOUNTIFSC /AADHAR c
tyPe
payqe count String (20) Payee account number N
paybe-ifsc String (11) Payee bank IFSC C :r' N
Conditional for NodaI account user when doing
VPA String VPA based transaction in UPI mode. This has to c Y
be same as "payee-va" tag

lnitiation mode 00=Defautt, 01=QR Code, 02=

Secure QR Code, 03=Bharat QR Code, O4=intent,
05=Secure Intent, 06=NFC, 07=BLE(Btuetooth),
initiation-mode Numeric(02) C Y
08=UHF(Uttra High Frequency), 09=Aadhaar,
10=5DK, 1 1=UPl-Mandate, 12=FIR(Foreign
ln ward Remittance), 13=QR Mandate, 14=BBPS
The purpose field is used speciatty for SEBI txn
00-Defautt, 01=SEBI, 02=AMC, O3=Travet, 04=
Purpose Numeric(02) Hospitality, 05=Hospitat, 06=Tetecom, C Y
07=insurance, 08=Education,
09=Gifting,'10=Other
Reference number Mandatory for creditcard
ref-id String c
payments
IMPS

IocatTxnDtTime String Transaction Date & Time (YYYYMiUDDHHmmss) Y N

beneAccNo Number(35) Beneficiary Account Number Y N

benelFSC String(11) Beneficiary bank's IFSC Code- 11 diqit Y N

amount Number Transaction amount to be transferred Y N

Transaction Reference Number that uniquely

tranRefNo String Y N
identifies the transaction at BC end

paymentRef Transaction lnfo, witt be send in NFS message-

String(50 ) Y N
max 50 char

BC customer's Name. This witt be used in the

senderName String(20) Y N
message send to NFS, Max 20 char.

mobite String(10) Remittance Mobite number- Max '10 char Y N

Retailer/CSP code (BC Specific Retaiter/CSP

retaiterCode String Y Y
Code).vatue to be passed as rcode
passCode String PassCode been generated by IMPS Y Y
bclD String Merchant's BCID Y Y
Corporate lD (mandatory onty for Nodat
crpld String C Y
account)

crpUsr
SMS Corporate User (mandatory onty for Nodat
String c
account)

aggrld String (100) Aggregator lD Y Y

NEFT
tranRefNo String (16) Transaction Reference Number Y N
Number
amount Transaction Amount Y N
(19)
 Number
flrc,", *r*
senderAcctNo Sender's Bank Account No Y N
35
Number
beneAccNo Beneficiary Account Number Y N
(3s)
beneName String (50) Beneficiary Name Y N

Beneficiary Bank IFSC Code.

ln case of lClCl Bank, this should be

'tctc0000011'
benelFSC String (11) Y N
ln case of lClCl Bank enabted cards, this shoutd
be'|C1C0001028'
For "VAP" IFSC shoutd be 1C1C0000103,
rcrc0000104, rctc0000106
String
narrationl Narration 1 (Originator of Remittance) Y N
(3 s'4)
String
narration2
(3s'4)
Narration 2 (Remittance information) o N

crpld Stri ng Corporate lD

crpUsr String SMS Corporate User Y

aggrld String (100) Aggregator lD

aggrName String Aggregator Name Y

urn String (40) URN Number Y N

'TPA'for lClCl as beneficiary Banks; 'RGS'for

other banks;
For Virtuat A/c payments Txn_type shoutd be
'VAP" & "RGS' and IFSC shoutd be |C1C0000103,
1C1C0000104 & 1C1C0000106 depending on the
txnType String
ctient codes created for the service of virtual
account number based coUection. This is
communicated during setup of this service for
any ctient. IMPS & RTGS txn wiU not atlowed for
virtual payments.
Conditional for NodaI account user with PWT
WORKFLOW-REQD String c Y
flow
RTGS
AGGRID String Aggregator ld
CORPID String Corporation ld
USER ID String User ld
URN String URN Number Y N

AGGRNAME String Aggregator Name Y

UN IQU EID String Unique ld Y N

OEBITACC Number Debtor Account no. N

CREDITACC Number Creditor Account no. Y N

Beneficiary Bank IFSC Code.

ln case of lclcl Bank, this should be

IFSC String 'rctc0000011 ' Y N

lclcl Bank enabted cards, this shoutd

ln case of
be'1C1C0001028'
AMOUNT Number Transaction Amount Y N

CURRENCY String Currency in which transaction hetd Y

 flrcrct ernx
'TPA' for lClCl as beneficiary Banks; 'RTG' for
TXNTYPE String
other bank6;
PAYEENAME String Payee name of transaction Y N

REMARKS Stri ng Remark by payee Y N

Conditionat for NodaI account user with PWT
WORKFLOW_REQD String c
ftow

1.6 Samole Reouest Packets

(1) Sample Request Packet for UPI:

{
"mobile": "7000000023",
"device-id": "1 901 601 901601901 601 901 60",
"seq-no":'1Cl5DC866EA6ADC427",
"account-provider" 1 "74" ,
"payee-va": "moto2.4@icici",
"payer-va": "uat@icici",
"profite-id": "2995692,
"amount": "1 ,00",
"pre-approved": "P",
"use-defautt-acc": "D",
"default-debit": "N",
"default-credit": "N",
"payee-name": "MEHUL",
"mcc": "601 1",
"merchant-type": "ENTITY',
"txn-type": "merchantToPersonPay',
'thannet-code": "MlClCl",
"remarks": "none"
"crplD": "APl3",
"aggrlD" : "AGGR0008",
"userlD" : "USER2",
"vpa": "mot02.4@icici"

]
Ptease note sample detaits for UAT testing:

. Ptease note, corplD, aggrlD & userlD is onty mandatory in case

of merchants opting for beneficiary
registration & vatidation API seMces)
. vpa tag is onty mandatory in case of Nodat account when vpa is plg:registered through bene registration
. Sequence tag vatue should always start with a prefix "lcl".

(2) Sample Request Packet for lrvtPs

t
"tocatTxnDtTime":"201 908081 61 038",
"beneAccNo" : "001 700000004",
"benelFSC":'HDFC092291 5',
"amount":"287.00",
"tranRef No":"1 23&56",
"paymentRef ' : "FTIransferP2A",
"senderName":"Ram singh",
"mobite':"9999988888",
 flrcrct e"rx
"retailercode": "rcode",
"passCode": "3f4dbbdad1 a241 bca994339c0d3f 3efd",
"bclD": "lBCFti00044",
"crpld":"CIBNEXT',
"crpUsr":"BALAKIRAN",
"aggrld": " AGGRID"
]
(Ptease note, ,aggrld, 'crplD'& 'crpusr'are only mandatory in case of merchants opting for beneficiary registration
& vatidation API services)

(3) Sample Request Packet for NEFT

I
"tranRefNo": "abc1 2345",
"amount": "1",
"senderAcctNo": "000451 000301 ",
"beneAccNo": "00M05C02777"
"beneName": "Mehul",
"benel FSC": "S81N0003060",
"narrationl ": "Test",
"crpld": " PRACHICIB1",
"crpUsr": " USER3",
"aggrld": " AGCRID",
"
ur n" : "7 59969775cff 4dcc8b8c63402e645da3",
"aggrName": " AGGRNA itE"
"txnType": "RGS"
" WORKFLOW_REQD": "N"

Please note sampte details for UAT testing:

. Debit Account: 000451000301

. Credit Account: 000405W2777
. For lClCl as beneficiary bank use IFSC as |C1C0000011 and 'txnType' as "TPA" and for Non-lClCl Beneficiaries
use IFSC as DLXB0000092 and 'txnType'as "RGS", virtuat accounts "VAP"
. WORKFLOW_REQD is an optional parameter in Nodal account ftow for users with transaction processing is
atlowed without workftow.

(4) Sampte Request Packet for RTGS

I
"AGGRID": "AGGRID',
"CORPID": " PRACH|C|Bl",
"USERID": " USER3",
"URN": "7ef3bc0d03ec495b9f 5fa320724ce94e",
"AGGRNAME': "AGGRNAME",
"UNIQUEID": "1C101 234",
"DEBITACC": " 00040500161 1",
"CREDIT CC": "000405002777",
"lFSC": "1C1C00000M",
"AI OUNT': "1.00",
"CURRENCY': "lNR",
'TXNTYPE': "RTG",
"PAYEENAME': 'ASDAS",
 "RE vtARKS": "Satary
Orcrct e"rx
for Payrolt Jan"
'WORKFLOW_REQD": "N"
l
Ptease note sampte detaits for UAT testing:

. Debit Account: 000451000301

. credit Account: 000405002777
. For lClCl as beneficiary bank use IFSC as |C1C0000011 and 'txnType' as "TPA" and for Non-lClCl Beneficiaries
use IFSC as S8IN0003060 and 'txnType' as "RTG".
. WORKFLOW-REQD is an optional parameter in Nodal account ftow for users with transaction processing is
atlowed without workf low.

(5) Sample Request Packet for UPI - IMPS (priority: - 1200)

t
"device-id":"c 1 6e561 d751?ac43",
"mobite":"99999888888",
"channe[-code":"GOOGLE",
"profite-id": "7759403",
"seq - no" : "1 C I bb6 0062b47 54450dM00209af f b30bb3",
"mpin": "NPC1,201 508zrw==",
"account-provider":"508534",
"account-number":"AXe1 72001 5d6ce948bae2cc55382925679,
"senderlFSC":"1C1C0006246",
"account-type":"UNKNOWN",
"payee-account" i" 0441234567 89 ",
"payee-ifsc" : "1C1C0000001 ",
"gtobat-address-type": "ACCOUNTIFSC "
"payer-va":"merchant2@icici",
"amount":"287.00",
"pre-approved":"A",
"use-default-acc":"N",
"def autt-credit" : "N",
"default-debit":"N",
"currency":"lNR",
"txn- type": "paytoGtobat",
"remarks":"1 paid cash bcz this was pending",
"mcc":"6011",
"merchant-type":"ENTITY',
"ref-id": "1 2345678",
"expire-af ter":"1 439",
"detiveryChannetCtrtl D":"ClB",
"tocalTxnDtTime":"201 701 091 61 038",
"beneAccNo": "001 700000004",
"benel FSC" : " HDF C9229 1 54",
"tranRef No":"cl 6e561 d751 2ac43",
"paymentRef ' : " 1 734567 89",
"senderName":"GOOGLE",
"retailerCode": "01 23",
"passCode": "0000"
"bclD": "lBCFti000zl4",

]
 fl,"rc, r"n*
(6) Sample Request Packet for UPI - NEFT (priority: - 1020)

t
"mobite": "7000000023",
"device-id":'190160190160190160190160",
"seq-no': "5DC866EA6ADC427",
"account-provid er" : "7 4",
"payee-va": "mot02.4@icici",
"payer-va": "uat@icici",
"prof ite-id" : "2995692",
"amount": "1 .00",
"pre-approved": "P",
"use-defautt-acc": "D",
"default-debit": "N",
"default-credit": "N",
"payee-name": "MEHUL',
"mcc": "6011",
"merchant-type": "ENTITY",
"txn-type": "merchantToPersonPay",
"channet-code":'MIClCl',
"remarks": "none"
"tranRefNo": "abcl 2345",
"amount": "1",
"senderAcctNo": "000405001 257",
"beneAccNo": "000451 000001 "
"beneName": "Mehut",
"benelFSC": "SBl N0003060",
"narration l ": "Test",
"crpld": "PRACHlClB1",
"crpUsr": "ABC",
"aggrld": "AGGR0028",
" ur n" : " 7 5996977 5cff4dcc8b8c63402e645da3",

"aggrName": "Abc"
"txnType': "RGs"

(7) Sample Request Packet for IMPS - NEFT (priority: - 0120)

I!
"locatTxnDtTime":"201 908081 61 038",
"beneAccNo": "001 7000000&1",
"benel FSC" : " HDF C9229 1 54",
"amounf':"287.00",
"tranRef No":"1 23956",
"paymentRef ' : "FT[ransferP2A",
"senderName":"Ram singh",
"mobiLe':"99999888888",
"retailercode": "rcode",
"passCode": "3f4dbbdad1 a241 bca994339c0d3f 3efd",
"bclD": "1BCFti00044",
"tranRefNo": "abc1 2345",
"amount": "1",
"senderAcctNo": "000405001 257',
 "beneAccNo": "000451 000001 "
Orcrct ernx
"beneName": "Mehut",
"benelFSC": "SBl N0003060",
''narrationl":'Test",
"crpld": "PRACHlClB1 ",
"crpusr": "ABC",
"aggrld": "AGGR0028",
" urn" : " 7
599 697 7 5cf f 4dcc8b8c63402e645da3",
"aggrName": "Abc"
"txnType": "RG5"

(8) Sample Request Packet for UPI-IIAPS-NEFT (priority: - 1230)

{
"mobite": "7000000023",
"device^id": "1 901 601 901601 901 601 901 60",
"seq-no": "5DC866EA6ADC427',
"account-provider" : "74",
"payee-va": "moto2.4@ic'ici'',
"payer-va": "uat@icici",
"prof ite-id": "7995692,
"amount": "1 .00",
"pre-approved": "P",
"use-default-acc": "D",
"defau[t-debit": "N",
"defautt-credit": "N",
"payee-name": "MEHUL',
"mcc": "601 1",
"merchant-type": "ENTITY',
"txn-type": "merchantToPersonPay",
"channe[-code":'MlClCl",
"remarks": "none"
"tocatTxnDtTime": "201 908081 61 038",
"beneAccNo": "001 700000004"
"benel FSC" : " HOF C9229 1 54",
"amount":"287.00",
"tranRefNo":"1 236456",
"paymentRef': "FTIransferP2A",
"senderName":"Ram singh",
"mobite":"99999888888",
"retai(erCode": "rcode",
"passcode": "3f4dbbdadl a241 bca994339c0d3f 3efd",
"bclD": "lBCFti000,l4",
"tranRefNo": "abcl 2345",
"amount": "1",
"senderAcctNo":'00(X05001 257",
"beneAccNo": "000451 000001 ",
"beneName": "Mehul",
"benel FSC": "S81N0003060",
"narrationl': "Test",
"crpld": "PRACHlClB1 ",
"crpUsr": "ABC",
 "aggrld": "AGGR0028",
flrctct arrx
" wn" i "759969775cff4dcc8b8c63402e645da3",

"aggrName": "Abc"
'txnType": "RGS"

1.7 Output Parameters:

Name Type Description

UPI
success Boolean True/False
reSPonse Number Response Code
message String Response Message
Ba nkRRN String Bank RRN number
UpiTrantogld String UPI Transaction Log ld
UserProfile String User Profite
SeqNo Number Sequence No.
MobiteAppData String Mobite App Data
PayerRespCode Number Payee Response Code
IMPS

Response String ActCode Description

ActCode String ActCode Vatue
TransRefNo Number Transaction reference no.
BankRRN String Bank Transaction Reference Number
BeneName String Beneficiary Name
=a NEFT & RTGS (SUCCESS) I

REQID Number Request ld of transaction

RESPONSE String Response message of transaction
STATUS String Status of transaction
UNIQUEID Number Unique transaction id
URN Number URN Number of transaction
UTR Number UTR number generated by Bank
NEFT & RTGS (FAILURE)
RESPONSE String Response message of transaction
ERRORCODE String Error code of the faited transaction
STATUS String Status of transaction
RESPONSECODE String Response code
MESSAGE Number Transaction message

(1) Response Packet of UPI (Success)

"success" : true,
 "response" : "0",
frrcrct aur*
''message" : Transaction Successfu[',
''8ankRRN" :'82191 1303721",
"UpiTrantogld" i " 1275303721",
"UserProfite" : "1 5980666",
"seqNo" : .1cl820f 8967 8241 4fddb9d1 1 e72b07566a",
"MobiteAppData" : "5UCCE5S",
"PayerRespcode" :'00",
"PayeeRespcode" : "00"
]

(2) Response Packet of IIAPS lsuccess;

{
"success': true,
"Response":'Transaction Successf u[",
"Actcode : '0'
,
"TransRefNo':'1 238456",
"BankRRN":'9270197 9 67 97",
"BeneName": "BENE &amp; CUSTOMER NA"
l
(3) Response Packet of NEFT (Success)

{
"URN": "263448",
"STATUS": "5UCCESS",
''UNIQUEID':' 3 12342543",
"RESPONSE': "SUCCESS',
"REQID": "275843"
"UTR": "455849"
I

(4) Response Packet of RTGS (Success)

''URN": "263448",
"STATUS": "sUCCE55",
"UNlqUElD": " 317342543',
"RESPONSE": "SUCCESS",
''REQ|D": "275E43"
"UTR": "455849"

(5) Response Packet of UPI lraiture;

:
"success" : fait,
"response" : "39",
"message' : "duplicate seq no from channel",
"BankRRN". : " 445U5645U",
"UpiTrantogld" : "1151 51",
"UserProfile" : " 1 1 4812.17',
"SeqNo" : "lCla97E81 6e9f914de669791fd15430da6b",
"MobiteAppData" : ""

(6) Response Packet of IMPS lraiturel

''success":fatse,
"ActCodeDesc": "Duplicate transaction",
 "Actcode": "094",
flrcrct ern*
'TransRefNo": "8031 1 2626398

(7) Response Packet of NEFT E RTGS lraiturel

'RESPONSECODE":" 1 00042",
"Nl ESSAG E":"Transaction with reference id 346712386 failed during processing, due to System Malfunction",
"STATUS":"FAlLURE",
"ERRORCODE":"10691 0",
" RESPONSE":"FAILURE"

(8) Response packet of Gateway Failure, common to all payment modes (failure)

t
"success":false,
"errorCode":"997",
"description":"Note : lnitaite Status check after Some time"
)

" Ptease note, the sampte response packet mentioned above

for NEFT & RTGS is standard. But, in some failure
cases, parameters RESPONSECODE, STATUS & ERRORCODE might not appear. RESPONSE and,t ESSAGE parameters witl
atways appear.

2. Composite Status - UPI

2,1 Description: This API wi[[ be used to check the transaction status of the UPI Pa yment.

lpriority - '1000, to be passed in headers for accessing UPI status or recon360

2.2 Endpoint:

UAT: https: / / apiban kinqonesandbox. iciciban k. com / a pi /v1 / composite -status

LIVE: https: / /apibankineone.icicibank.com/api/v1 /composite-status

2.3 lnput Parameters:

 flrcrct eunx
Mandatory
Name Type Description (Y/N)
id tring nique device Token. Token should be unique for per
annel-user.

bite umber bite Number of the user.

is will be a txn-id generated by the Mobite APP. This id

-no String tt be used in the NPCI Common Library at the time of
ncrypting the OTP/MPlN.

hannel-code tri ng code for the source apptication from which the Y
ransaction witI be initiated.
I

lD of the profite returned in the response of the 'register

rofite-id ln,.* ( mobile/store-acc.detaits'APl. This wilt uniquety identify
user's profile.

-seq-no tring No of the original transaction for which we are

ing the status.

ate 0ate DD/YYYY format, Date to be of transaction initiated

ate

360 t n ng xed vatue

or Value "N", API witt be routed to status APl, API wilt
etch the status avaitabte over switch
or vatue "Y", API witt be routed to Recon API for knowin
Deemed approved or pending transaction status
)

2.4 Request Packet:

SamDle reou€st oacket for UPI status e quirv
t
''
date" 1 " 07 / 22 / 202 1 ",
"recon360': "N",
"seq-no":"Unique id every time you hit the APl",
"channet-code":"imobite",
"ori-seq-no":"lClf 5DfdC8c6ddgdcfddfdffdfhfdj2',
"mobite":"9956979792",
"profite-id" :"323927?",
"device-id":"1 9ee1 bee5d349d1 1 "
]

Samote request Dacket for UPI Recon status

{
"dale": "02I22I2021",
"recon360': "Y",
"seq-no':"Unique id every time you hit the APl",
"channe[-code": "imob'i [e",
"ori-seq-no":"SBlbb831 9eefl c74f 1 6aa8c92&0552d2b0",
"mobite' : "9956979792",
 flrcrct ernx
"prof ite-id":"3239272",
"device-id":"1 9ee1 bee5d349d1 1'
]

Please note sampte detaits for UAT testing:

. Ctient has to pass "N" value in recon360 tag to get the UPI transaction status response and for Recon360 the
value to be passed is "Y"
. Ctient wit[ receive two different responses for status and UPl360.
o Recon360 to be used for "Deemed" cases post using the status API and on T+2 working days of the originat
transactions.
. Last 5 days transaction status witl be present over UPI status enquiry at any point of time.

2.5 Output Parameters:

Name Type Description
UPI status API response
Success String Tag denoting service, not to be considered for Transaction
Response Number Response code of the API. Response code "0" indicates the
'success response". Not to be considered fir
Message String Response code description message
BankRRN String The reference number of the transaction.
UpiTranlogld String The Transaction lD Benerated by Switch.
UserProfile String Profile Id of the user
MobileAppData String Denotes current transaction status of the RRN
SeqNo String Seq-no input parameter \,{ill be echoed back.

R€con 360 API response

PayeeAccount Numeric Beneficiary account number
Transaction'Iype Alphanumeric Default value as PAY for UPI payouts
PayeelFSC Alphanumeric IFSC of the payee account
Originatingchannel Alpha Default value " uPr.NPCI'
OriginalTransactionStatus Alpha Original transaction status
PayeeName Alpha Payee Name
PayerlFSC Alphanumeric Payer IFSC
PayerName AIpha Payer Name
PayerVPA Alphanumeric Payer \rPA
MerchantlD Alphanumeric Merchant ID
PayeeVPA Alphanumeric Payee VPA
RRN Numeric RRN
TransactionAmount Numeric Transaction Amount
PayerAccountNumber Numeric Payer Account Number

DateTimeStatusChange Alphanumeric Date and Time of Status Change

 Orcrct ern*
CurrentTransactionStatus Alphanumeric Current Transaction Status/updated transaction status of Original
transaction
Success responses: Credit confirmation received, Success, Completed
Failure response: Fai-led and Retumed received
Pending resDonse: Dqemed approved, Suspect, Timeout
SequenceNumber Alphanumeric OriBinal Sequence number
IRC Numeric IRC
DisplayMessaBe Alphanumeric Display Message on API call
OriginalTransactionDateTime AJphanumeric Original Transaction Date and Time

2,6 Response Packet:

UPI Status API Respone:

t
"success": true,
"response': "0',
"message': Transaction Successfut",
'BankRRN": "1U7 1 41 51 385",
"UpiTranlqld" : " 3048441 6 1",
"UserProfile": "7996298",
"SeqNo": "123",
'l,tobiteAppData": foriginal-txn-rrn-:
1A6719317736
"originat-txn-response-code': 0
"original"txn-message": "5UCCESS"
l
"PayerRespCode": "00",
"PayeeRespcode": "00"
]

UPI recon 360 API response:

t
"FayeeAccount" : "XXXXX7639"
'TransactionType" : "PAY',
"PayeelFSC":'SBlN0003 1 60",
"OriSinatingchannet': "UPl. NPCl",
"OriginalTransactionStatus": "Deemed Approved",
"PayeeName": 'Mr S VIMALAN",
"PayerlFSC": "",
"PayerName":'Yignesh .",
"PayerVPA": "vigneshl 8895@oksbi",
' MerchantlD": "SBlbb83 1 9eef/c74t 1 6aa8c92640552dzbo",
"PayeeVPA" : "vimatan281 096@0kicici",
"RRN": "000320706502",
'TransactionAmount": "500",
"PayerAccountNumber" : "}}XX}xXX)o0fiX4976",
"DateTimestatuschange': "2020-01-29 1t5.14:32.0",
'turrentTransactionStatus": "Credit Confirmation Received",
"SequenceNumber": "SBlbb831 9eef7 c7 4f 1 6aa8c97640552d2b0",
 fl,crct ernx
"lRC": "0000",
"DisptayMessage":'Success. 223813",
"OriginalTransactionDateTime": "2020-01 -03 20:38:48.0"
)

3. Composite Status- IMPS

3.1 Description: This API wil[ be used to check the transaction status for IMPS.

3.2 API Endpoint:

UAT: htt :l la ibankin onesandbox. iciciban k. com / a i /vl /com osite -status
Live: httos: / /aoibankineone. icici bank. com / a pi/vl /composite-status

3.3 lnput Parameters:

ilandatory
Name Type Description (Y/N)
ransRefNo umber TA nsaction Reference Number that uniquety identifies
transaction at BC end

Passcode tring sscode been generated by |MPS

Y
bclD String f",..n ant's BCID
Channet-code Atphanumeric ChanneI code Conditionat
Date Date i\^M/ DD / YYYY format, Date has to be transaction
initiated date
Recon360 String lFixed vatue Recon360
]for vatue "N", API witl be routed to status APl, API witt

3.4 Request Packet:

IMPS Status enquiry request packet

{
"t ransRef No": "1 )4755",
"passCode": "3f4dbbdad1 a241 bca994l39c0d3f3efd",
"bclD": "18CF1i00044",
"recon360":"N",
"date":" 02I16I2021"
]
lA,lPS recon 360 request packet:

{
"date" .'07 t 1612021" ,
"recon360':"Y",
" trdrsRefNo ": " 8442310086",
 l?rcrcr eun*
)

Please note sample detaits for UAT testing:

Ctient has to pass "N" vatue in recon360 tag to get the IMPS transaction status response and for Recon360
the vatue to be passed is "Y"
Recon360 to be used for error codes 1 1&30 post using the status API and on T+2 working days of the originat
transactions.

3.5 Output Parameters:

Name Type Description

IMPS status enquiry response

Code umber sponse code of the APl. Response code "0" indicates the success response
iN

trp""* -ff.'* ansaction Response

_L
Ba nkRRN lNu mber nk RRN number

BeneName String Beneficiary Name

ra n RefNo lNu mber Tansac tion Reference Number that uniquely identifies the transaction at BC
nd
aymentRef tring Payment Reference
L_,
iTra nDateTime l*I te ETansactlon Oate
I
ina ti me
iNumber hmount
[m"r.t
EA neMMlD lNumber Beneficary MMID
I

B eneMobite lNmn"r. Aeneticiary tvtoUite NumUer

eAccNo Number Beneficiary Account Number

en e FSC Beneficairy IFSC

lB
Fn'u
RemMobite Number ender Mobite Number

RemName t
S TI ng Nanre
fena-
tailerCode String Code
lRetaiter
IMPS recon 360 response parameters

hranRefNo Number Reference Number that uniquely identifies the transaction at BC end
[ransaction
PaymentRef

Frpuy rra.*re"
lYl String
avment Reference

ansaction original status

umb € nk RRN number

OriginalTransactionStatu Number riginal Transaction Status

 Orcrct errx
tring
Transaction Status/updated transaction status
uccess responses: Credit confirmation received, Success, Completed
rrentTransactionStatu responses: Failed, Retumed received.
Deemed Timeout
riginalTransactionDate tri ng
me DM MYYYY
mber
ransactionAmount nsaction Amount

neficia ame eneficia Name

neficiaryAccountN um
er umber eneficiary Account Number

ciaryMobileNo umber neficiary Mobile No

ciaryAadharNumb
r umber neficia Aadhar Number

neficia rFsc in neficia IFSC

mitter Name tring phanumeric(50) Rem itter Name

m itterAccou ntN umbe
r umenc mitter Account Number
itterMobileN um ber Numeric
m mitter Mobile Number
riginatingchannel iBinating Channel
tring

3.6 Response Packet;

I/UPS status enquiry response:

{"lmpsResponse":
I
"Actcode": "1 1",
"Response": 'Time out at NPCI",
"BankRRN": "92'l 01 1 806647",
"BeneName": "",
''TranRefNo": " 3247197 400487 395" ,
''l)aymentRef ': "FTTransf erP2A",
"-TranDateTime ': '29-07 -7019 1 1:37:13",
"Amount"; "2000",
"UenefilrrilD": "9028001 ",
"tleneMobite": "",
"tleneAccNo": "063401 1 0001 646",
"BenelFSC": "UC840000634",
"Reml"{obile": "8800683242",
"FlemName": "ACTAS TECHNOLOGIES PRIVATE LlMlTED",
''RetaiterCode": "rcode"
l
IMPS recon 360 response:

"recon-api-aesponse" :{
"heade.s": {
"message-type": 1401,
"proc-code": 455002,
"channel-code": "mobi1e",
 Orcrct sanx
"stan": "STAN000002 ",
"response-code" : "0000",
"nesponse-message": "Success, "
),
"parameters": {
"index": {
"ld": 0,
"parameter": I
t
"name" : "Benef i.ciarylttobileNo",
"va1ue": {}
L

i
"name" : "RemltterAccountNumben",
"value" : "Xn(x)(xXX0190"
\
t
"name": "Benefici.aryl FSc ",
"value" : "A8HYO065632"
),
{
"name" : "Originatingchannel",
"value": "Internet"
)
{
"name"i "Ori.ginalTransactionStatus",
"value": "Suspect "
)
{
"name" : "BeneficiaryNaflie",
"value" i {}
)
{
"name" : "BeneficiaryAadharNumber",
"va1ue": {}
)
{
"name": "RRN",
"va1ue" : "0938134S5317"
)
{
"name" : "TransactionAmount",
"value":1.84
)
t
"name" : "Benef icial'yAccountNumber",
"value" : ")(XUXXXXXXX2259"
)
t
"nane": "t1obi leNumbe n ",
"va1ue": 8898S26449
i
{
 flrcrct ernx
"name": " Cu.ne ntTr ans act ionStat us ",
"value": "credit confirmation Received "

t
"name": "TranRefNo",
"va1ue":8442310985
),
t
"name': "IRC",
"va1ue": "0091"
),
{
"name": "Displ ayMessage ",
"value": "Tirne out at NPCI"
i,
{
"name": "Origi nalT ran sa ctionDateTime ",
"va1ue": " 12- F EB -2OOO.OO.OO"

)
t
"name": " Remittenl.laole ",
"value": "Paytmol"
)
l
)
)
)
)

4. Status Check for NEFT & RTGS

NE transaction processing essentiatly takes ptace in two steps - a) There is a debit in to remitter
nt first, b) Fotlowed by transaction getting submitted to RBI for processing with the time lag.

For NEFT status enquiry there are two sets of APls availabte from lClCl bank given below as -
1) NEFT debit confirmation API - Provides the status of the debit in remitter a/c
2) NEFT credit confirmation API - Provides the status of the credit in beneficiary a/c
Status Enquiry -

a. For money transferred to lClCl Bank account bene -

For the amount transferred within lClCl bank the remitter needs to onty use the first API ie.
Debit confirmation APl.
 flrcrct arnx
The remitter needs to fire this API and if the response received in status fietd is "SUCCESS"
in that case the transaction can be marked as successfutty processed.
For the status received as faiture(Response tag vatue to be success) the same can be marked
as faited and that particutar transaction can be re-initiated. For any other status remitter
should recheck the status after 2 hours. This re-check is required to be done onty once. ln
case the status does not change to a definite success or failure, in that case no further
action is possible and this transaction is to be marked as 'pending'.

Att pending transactions are to be reconciled with the remitter bank statement to ascertain
the final status of the transaction. ln case of no respective debit is found the transaction
can be marked a failed & fresh transaction can be re-initiated. ln case the debit is present
in the account the transaction can be marked as successful.

Additionatty, this API can atso be utilized to fetch the UTR number for the transaction in
case the same is not received with initial

b. For money transferred to non lClCl Bank account bene -

It is a two-step process to identify the finat status for these transaction.

1. The remitter needs to fire the first API (Debit) and if the response received in status
fietd is "SUCCESS" onty and onty in that case the remitter shoutd proceed to step 2 tisted
betow.

For the status received as faiture the same can be marked as faited and that particutar
transaction can be re-initiated. For any other status remitter should recheck the
status after 2 hours. This re-check is required to be done only once. ln case the status
does not change to a definite success or failure, in that case no further action is possibte
and this transaction is to be marked as 'pending',

Att pending transactions are to be reconcited with the remitter bank statement to
ascertain the final status of the transaction. ln case of no respective debit is found the
transaction can be marked a failed & fresh transaction can be re-initiated. ln case the
debit is present in the account then the remitter can proceed to step 2.

2. Understep2, the remitter should invoke the secondAPl (CreditAPl or lncremental status
API) with the requisite request packet as documented in API document. Once the status
is successfulty received as "amount credited to beneficiary" transaction can be marked
as successful.

3. lt is possibte that in some scenarios the status is received as "posted to RBl". This status
is provided for the transaction which the beneficiary bank has not provided the uttimate
status and after 5hrs of the transaction the status would be changed ,,paid',. ln such a
scenario RBI has provisioned for 72 hrs for the beneficiary bank to update the final status
of the transaction. However, if the status does not change post 72 hrs the remitter can
mark these transactions as successfut.

4.1. Description: RTGS response received over composite status API is a terminal response.
 lrrcrct aanx
4.2. Endpoint URL:

UAT: httos: / / aoi bankineonesandbox. icici bank. com / a pi/v1 / com oosite - sta tus
Live: h ttps: / / apiban kinqone. icicibank. com / api / v1 / com posite -status

4.3. lnput Header:

x-priority = '0010' for NEFT and '0001 ' for RTGS

4.4. lnput Parameters:

AGGRID

CORPID
I String

String
Aggregator ld

Corporation ld

USERID String User ld Y

URN String URN Number Y

UNIQUEID String Unique ld

(Pass the value of 'tranRefNo'in this parameter for

NEFT status check)

Sample Request:

t
"AGGRID": "AGGR0001",
"CORPID": "PRACHICIBl ",
"USERID": "USER3",
"URN": "1288883",
"UNIQUEID": "abc1 2dk3d7dd4hc5ducdfe"
]
4.5. Output Parameters:

i._+---.,.-
URN Number URN Number of transaction

STATUS String Status of transaction

UNIQUEID Number Unique transaction id

RESPONSE String Response message of transaction

UTRNUMBER Number UTR Number of the transaction

Sampte Response:

{ XML": {
"STATUS": "SUCCESS",
"URN": 1288883,
"UNIQUEID": "abc12dk3d7dd4hc5ducdfe",
"UTRNUMBER": "056931871",
"RESPONSE": "SUCCESS"
 Orctct eanx
)

5. lncremental Status API for NEFT

5.1. Descri tion: To be used after 30 minutes of original transaction once the NEFT batch is
processed. API gives the terminal status of transactions for txntype "RGS"

Note: it is mandatory to use status API before firing incremental APl.

5.2. Endpoint URL:

UAT: https://apibankingonesandbox.icicibank.com/apilv1lct BNEFTStatus

Live: https://apibankingone.icicibank.com/api/v1lCtBNEFTStatus

5.3. lnDut Parameters:

Name Type Description

String Aggregator ld
AGGRID
String Corporation ld
CORPID
String User ld
USERID
String UTR Number
UTRNUMBER
String URN Number
URN

5.4. Sample r equest

{
''URN": "2634A8",
"AGGRID": " CustoXXX ",
CORPID": "ICICXXXX',
"USERID": "Deepak",
" UTRNUMBER": '455849'
I

5.5. Output Para meter

Name Type Description

String Status of the UTR. This is th e fietd which needs to
be referred, betow value to be considered for finat
status
STATUS Success: Amount credited t o Beneficiary
 fl,",", *nu
Faiture: Amount refunded to Remitter
Pending: paid
Retry with vatid detaits: FAILURE, lnvatid
Transaction lD, UTR missing
String UTR Number
UTRNUMBER
String Date of Credit
CreditDate
String Success/ Faiture
Response
String Reason for transaction failure app[icable only
REASON in case of a failure transaction

2.4 Sample Response

t
"STATUs":"Amount credited to Beneficiary.",
" UTRNUMBER" :"XXXXXn(n0(,
"CreditDate":"DD,filfil,YYYY HH:Mm:SS AM/Pi{",
"Response":'SUCCESS"
..REASON":'"'
1

When Txn id or UTR no ls not exist

t
SIATUS:,,FAILURE,,,
ErrorCode:"999922",
Message:"lnvatid
Transaction ld. .
Response: "Faiture"
]

6. API Name: Beneficiary Registration

6.1. Description: Beneficia ry Registration API is mandatory for Merchants transacting from
Nodal Account. Hence, before any composite API request, the ctients are required to first
fire this APl. Our systems wit[ configure the ctients in such a way that first we shatl vatidate
the beneficiary registration, and then process the payment request.

There are two such APls. One registers the beneficiary on the basis of account number &
IFSC which would suffice the payment needs for IMPS, NEFT & RTGS modes. Other API
registers beneficiary on the basis of Virtual Payment address which wi[[ suffice payment
needs for UPI mode.

For clients with existing ALIAS lD, the default configuration for this API witt not work.
Client needs to detete their existing ALIAS lD through CIB portal and create a new ALIAS
lD simitar to the existing corporate user lD. For exampte, a client has ALIAS ,l[ -as
'lClClBank'and corporate user lD as 'Bank12345', then ctient needs to delete the existing
ALIAS lD i.e. 'lClClBank' through CIB portal and create a newAL|AS lD as '8ank12345' which
has to be simi[ar to the corporate user lD.
 Orcr"t Bank
6.2. Beneficiarv Reeistration throu qh account & IFSC
7.2."1 API Endpoint:
UAT: https://a p iba n kingo nesa nd box. iciciba n k.com/a p i/Corpo rate/C lB/v1/Ben eAd d itio n

Live: https://apibankingone.icicibank.com/apilCorporate/Cl B/v1lBeneAddition

7 ,2.2 lnput Parameters:

Type (Max char Mandatory

Name Description
limit) (Y/N)
Crpld NVARCHAR2 (32) Ctient lD in Corporate lnternet Banking.
CrpUsr (32) Customer lD under Client l0 in Y
INVARCHAR2 Corporate lnternet Banking
BnfName NVARCHAR2 (80) Beneficiary name. Y

BnfNickName NVARCHAR2 (80) Beneficiary Nick name. Unique for Y

every request.
BnfAccNo NVARCHAR2 (32) Beneficiary Account number
PayeeType CHAR (1) Ctient need to pass respective Payee
type for bene registration 'O' for other
banks & W' for within bank WlB. Y
IFSC NVARCHAR2 (32) Bene user IFSC. But for FT static IFSC -
shoutd be pass by ctient 1C1C0000011

URN
R_ID NVARCHAR2 (100)

NVARCHARz (40)
lD of the partner
hardcoded by
to be provided and
lclcl Bank.
This a unique vatue that partner wilt
assign to each registration from his end
I
for security and recon.

7.2.3 Sample Re quest:

"Crpld" : "PRACHlClBl",
"CrpUsf':"USER4",
"BnfName" : "AnshumanMishra",
"BnfNickName" :'Ansh",
"BnfAccNo" : "000405001257",
"PayeeType" : "W,
"lFSC" : "1C1C0000011",
'AGGR_lD" : "AGGR0002",
"URN" : "3kCy4sPuSqDNi4kggXJloE568221 "
l
7.2.4 Output Parameters:

Name Type Description

Message NVARCHAR2 Status message of request
 fl,",", *rn
Responsi NVARCHAR2 Response SUCCESS OR FAILURE.
ErrorCode String Error Code

Response:Success
{
BNF_l[):"4836",
Message:"You may not be abte to make fund transfer immediately with newty added payee, please
check payee status before proceeding",
Response:"SUCCES5"

Response:Failure
t
Message:"lnvatid Corp Id or User ld or Aggregator ld is passed.",
ErrorCode:"9906",
Response:"FaiIure"
]

7.3 Beneficiary Registration API through VPA

7.3.1 Description: ThisAPl witt register beneficiary on the basis of VPA essentiat for UPI
payment mode for Noda[ account hotding merchants.

7.3.2 API Endpoint:

UAT https://apibankingonesandbox.icicibank.com/api/corporate/ClB/VPA,/v1lBeneAddition

Live: https://apibankingone.icicibank.com/api/CorporatelClBlVPNvT /BeneAddition

7.3.3 lnput Parameters:

Type (Max lrtandatory

Name Description (Y/N)
char timit)
AGG RID String Aggregator ld Y

CORPID String Corporation ld

USER ID string User ld

URN String URN Number

VPA String ALIAS ID

7.3.4 Request Packet:

 frrcrct arrx
{
"aggrlD" : "PRACHICIBl',
"corplD":"USER4",
"userlD" : "AnshumanMishra",
"urn" : "'1234567",
"vpa" : "testo@icici",
,t
)

7.3.4 Output Parameters:

Type (Max
Name Description
char limit)
Message String Message

Response tring Response witl be'Faiture' or'Success'

_t:
ErrorCode
l String Error Code

7.3.5 Request Packet:

Response:Success
t
tsNF tD: '4836 ',
Message:"You may not be ab(e to make fund transfer immediatety with newty added
payee, ptease check payee status before proceeding.,,
Response:"5UCCE5S"
l

Response: Fallure
i
Message:"lnvatid Corp ld or User ld or Aggregator ld is passed..,,
ErrorCode:"9906",
Response:"Failure"
]

7. CIB Registration API

7.1. Description: This is a on e-time API which is required to access NEFI RTGS & Beneficiary
Registration APls.

7.2. API Endpoint:

UAT: https://aoiba nkinsonesandbox.icicibank.com/aoi/Coroorate/CtB/vUReeistration

Live: httos://a piba n k ineo ne. iciciba
n k. com/a pilco roo ratelClB/v 1/Resistration

lnput Parameters:

Type (Max
Name Description Name
char timit)
 Orcrcr arrx
AGGRNAME

AGGRID
I tring

String
Aggregator name

Aggregator ld Y

CORPID String Corporation ld Y l

USERID String User ld

URN String URN Number

ALIASID Stri ng ALIAS D

I =)

7 .3. Sample Request

t
''CORPID":"<Corp ld>"
"USERID":"<user id>"
'AGGRNAME":"<Partner
name>"
"AGGRID":"<Panner
id>"
"URN":"<URN>"
'BANKID":"lCl"

Output Parameters:

Type (Max Description

Name
char limit)
AGGRNA,AIE Aggregator name

AGGRID
-[IT Aggregator ld
1'IT
CORPID ng Corporation ld
11
USERID String User ld

URN String URN Number

*;p"^* String Response

l
Message S tri ng tvtess ag e
]

3. CURL COMMAND

Sample Curl command for onlY UPI:

 fl,",c, ru*
curt -X POST \
https: / /apigwuat.icicibank.com:8443/api/vl /composite-payment \
-H apikey: .apikey, \
-H'content-type: apptication/json' \
-H 'x-priority: 1000' \
-d 't
'device-id":'a2f a806f 843b3538",
"mobite": "90467 8057A" ,
''channet-code": "GOOGLE",
"profite-id : "1147846",
"seq - no" : lLl6a7 37b?eb1 764b1 f 8da0fb62ed9 11 6ae",
"pre-approved": "M,
"payer-va":'ankan.k.e.s.h0045-40@okicici",
"amount": "120.00",
"remarks"; UPl ,
''account-provider": 508534",
"account-number" :' A'r'61 c7 d43c47fc0c51 3ad9283dcO539d90",
"senderlFSC": "lClC0001 937",
"account-type": "sAVlNG5",
"use-defautt-acc": "N,
"defautt-credit": N",
"defautt-debit': "N",
"currency":'tNR",
"ref-urt : "6ttps: / /www.exampte.org",
''payee-va : "good@icici",
"txn.type": payRequest'
r
 Orcrct ernx
4. SECURITY

r API Key needs to be passed in the header (apikey) and merchant lP witl also be required for lP
whitetisting.
. API Key: to be shored by lClCl teom.
. API request and response to Merchant is secured using advanced and agreed upon encryption
atgorithm agreed to maintain data confidentiatity and integrity.
. API Gateway uses the standard authenticating and authorizing process for the incoming
request from merchant and for maintaining the integrity and confidentiality we appty state of
art Encryption/ Decryption atgorithm.
r Please refer betow given steps for Encryption & Decryption process.

4.1 Encryption & Decryption Process

Sample Encrypted Request to be sent to Ctient (JSON):
t
'kequestld": "",
'|ervice": "PaymentApi",
'hncry1:tedKey":
"oGbmUi JJNBuwQaSLKb3wfRZk/cT2vo2yBNNuqjNHDWECl44WxC8iKqBpJAgqTreFKC4SHNUmNPRDyal AvmQTx l L+lEA
dEsgFEWNurZuWTvZpk4yT JrchglrzgKptBf+JfJUkSMoTNR3Saxel6EYtckkD13AGWTWJZmhcEoArv\MXRws/ hLVmaNHC/nOj
CNqqBd4tOOAzdJh/ HADRVI+YAJKT8dE4xgNTt+UXl zAooWhza+TsWEHfxzQlaTzaiTWSa/wiJD3uDTmk5vTi WY/fKJBquCuz
I,ATtbtvigDhmbTdLVLuXEVMiNqrtErWNl0uVaagl jg+ull,JlyDSxjPFi5yEpKWcT+T50llDnCvkCFDygqasDsPL24qOjYk4XavTZv
wC rir pAa VN lt t<V nLzVEt Eh9462ye+fa i 8fZiMt/3fwYeNgdgngi5R6VOFbXSuZJYPSci9kooqzT3hl nzFtps60rUEDoGlkcvm9waJ
U3WT8VH5mldGfGwJ'ii(luVHmi/huzEXgv4w3mWTRDGgmOuKlmkqki*XWgyBoJvVmsLdO+cBaym/seZP3+zdfh09AWSl2t
DLMVfojDjzoDsFN2miUFgHKgmbtbXgvsnReoGqx/ Ksi\,.zmZNLmDmtgSeR4ZgLnLni4rt4OtkDv5y/ mxrvltl-iMBUUUajkw6oS
6NnhEG895Yo=",
"oaepHashingAlgorithm": "NONE",

"encryptedData":
"wBJSefiinJVtobhI cJR553w6Ay6b8/2frcjxvdZl BsnxztsutTHaSlFt4PoZD+lhdtRShwdKgz3yJYlisGV/KKpy&lSY3DlLOpbkqEa
0Qq0g=",
"ctienthlfo": "",
"option.tlParam": ""
]
4.2 Fietd Description:

Field Description Data Max Mandatory Permitted Values

TyPe length
requestld Unique identifier String 64 No
for the request.
Not being stored at
any teve[.
 frrctct aunk
service type Service Name ; String Yes
ldentifying the
backend service
name

encryPtedKey One-time use AES String. Yes

key encrypted by Base64-
the Ctient's pubtic encoded
key. data
Requirement is for (case-
a 128-bit key (with insensiti
256-bit key ve)
supported as an
option).

oaepHashingAtgor Describes the String 6 Yes Vatue : NONE,

ithm atgorithm used for Meaning :
Asymmetric RSA/ECB/PKCS1 is used
Encryption of one for Asymmetric
time AES key. Encryption
Vatue:5HA1,
Meaning : RSA/NONE/
OAEPWithSHAI AndMGF
l Padding OR
RsA/ECB/
OAEPWithSHAIAndMGF
l Padding
 Orcrct arnx
lv The initialization String. 24 Yes, if lV is not Exactly 16 bytes actual
vector used when Base54- part of encrypted vatue to match the
encrypting data encoded data itsetf. Leave btock size
using the one-time data btank otherwise.
use AEs key. (case- For the response
insensiti data encrypted at
ve) lClCl end, lv witt
atways be part of
encryptedData
itself and it is
randomty
generated for
each request.
can be retrieved
by Ctient by
retrieving the
first 16 bytes of
Base64 decoded
encryptedData

encryptedData Contains the String. Yes

encrypted Base64-
dataPaytoad object encoded
containing the data
business (case-
information. insensiti
Encrypted by the ve)
ephemeral AES key
using
AEs/CBC/PKCS5Pa
dding.
Sampte
unencrypted
obiect:
Ptease refer first
section of
document for a
sam ob ect.
ctientlnfo CtientlP or other String No
information

optionaIParam Reserved for String No

future use
 fircrct e"nx
5. ENCRYPTION-DECRYPTION PROCESS

5.1 For Composite Payment, Status Check APls and CIB APls

For encryption of request at lClCl:

SesionKey = Randomly generated string of tength 16 (OR 32).

encryptedKey = Base64Encode(RSA/ ECBi pKCSl Encryption(SesionKey,lClCtpubKey. cer))
lv = lnitialization vector- Exactty 16 bytes actuat value to match the btock size
encryptedData = Base64Encode(AES/CBC/ pKCS5padding(Request, SessionKey, tV))

For encryption of response at lClcl:

encryptedKey = Base64Encode(RsA/ EcB/pKcsl Encryption(sesionKey, ctientpubKey. cer))

Session key is nothing but randomty generated string of tength 16
tOn :Z).
encryptedData - Base64Encode(AES/CBC/pKC55padding(Response, SessionKey))

For decryption of response at Ctient:

IV= getFirstl 6Bytes(Base64Decode(encryptedData)

sessionKey = Base64Decode(RsAi EcB/pKcsl Decryption (encryptedKey,ctientprivateKey. p12,
))
Session key is norhing bur randomty generated stiing of tengiir 16 (Oii 32)
Response = Base64Decode (AES/cBci pKcs5padding -DecryptionlencryptedData,sessionKey,
tv))
or
steps for Encryption
I) Generate 16 digit random number. Say-RANDOMNO.
2) Encrypt RANDoMNo using RSA/ECB/pKCS1 padding and encode using Base64. say encryptedKey.
3) Perform AEs/cBc/pKcsspadding encryption on request paytoad usiig nalioo,rlr.io
ini tiatization vector. say encryptedData.
*
[Jv ina rr-
4)N ow client may choose to send lV in request from one of betow two options.
a. Send 8ase64 Encoded lV in .,iv" tag. (Recommended Approach)
b. Send tV as a part of encryptedData itsetf.

bytes[ iv = lV;
bytes[] cipherText = symmetrica[y encrypted Bytes (step3)
bytes[] concatB = iv + cipherText;
encryptedData = B64Encode(concatB);

5) Perform AES/ CBC/ pKCS5padding encryption on DATA using RANDoMNo as key and
Base64encoded RANDOMNO as lV. Say ENCR_DATA.

Steps for Decryption

1) Get the lV- Base64 decode the excryptedData and get first 16 bytes and rest is encrypted response.
bytes[]lV-getFirstl6Bytes(Base54Decode(encryptedData)
-
2) Decrypt encryptedKey using atgo (RSA/ ECB/ pKCSl p;ddjng) and Ctient,s private key.
3) Decrypt the response using atgo (AES/CBC / pKCS5paddingJ.
4) lgnore first 16 bytes of response, as it contains lV

6. FAQs
1 . What is composite Apl?
 flrctq a"nx
Ans: One single API which witt accommodate payments for UPl, IMPS, NEFT & RTGS.

2. How do you know the status of the transaction lf there is no response recelved for the fired API?

Ans: There are status check APl.

3. How do you know the preferred Payment mode in the request?

Ans: Through lnput Header 'x-priority'.

4. What is 'x-priorlty'?

Ans: .x-priority' is a 4 digit input header parameter which determines the payment mode. The first,
second, third ind fourth digit sets the priority for UPl, IMPS, NEFT & RTGS respectively.

5. Can we process a single payment mode?

Ans: Yes. Put the vatue "l' against the preferred payment mode and rest a[[ as '0'. Therefore, in case
of just UPl, IMPS, NEFT & RTGS, x-priority shatt be 1000, 0100, 0010 & 0001'

6. Can we process more than one payment modes?

1020 is
Ans: yes. ln case, UPI is preferred and IMPS is fattback, then x-priority shatt be '1200'. Simitarty,
UPI preferred and NEFT as fatlback and so on.

7. Will the request parameter change for more than one Payment modeAPl?
Ans: yes. The request packet needs to include the mandatory parameters for att the
payment modes
selected.

8. ls Beneflciary Reglstratlon API Mandatory?

Ans: No. lt is onty mandatory for ctients transacting from Noda[ account'

9. How do you do the status check of Beneficiary Registlation API?

Ans: Fire Beneficiary registration API again, and you'll receive a response, 'Beneficiary already
registered'.

1O.How much tlme does beneflclary registratlon API takes to register the beneficlarles?
is
Ans: Beneficiary Registration API is real time APl. As soon as the API response is received, Beneficiary
registered on the Data base and the transfer API can be processed'

11 .What ls CIB registration API?

Ans: This is a one-time API that registers ctient on CIB which is our internal system. This
is required for
ctients to use the Beneficiary registration, NEFT & RTGS APls.

12. How approval is done for CIB registration in UAT or production'

has to login
Ans: ln UAT approval is done at back end post firing the registration APl. ln production client
CIB portat, seiect connected banking and approve from pending approvals'

'l 3.What is required from cllents' end for testing?

Ans: lP addresses & 4096 Bits Public key certificate.

14,Why is lP address required?

 Ans: ln order to maintain the security, we whitetist ctient,s lp addresses.
flrcrct srnx
1 5. What is 4096 Bits Public key certificate?
Ans: Composite API witt fottow encryption and decryption mechanism to send and receive request &
response from ctient's end. Every certificate fite witt have two components, i.e. pubtic Key ceriif.icate
& Private key certificate. Pubic Key Certificates are used to encrypt and Private key certificates are
used to decrypt.

The ctient witt use lClCl Bank's pubic key certificate and encrypt the payment request.
lclcl Bank witt
decrypt the payment request using our private key certifitate ih"n proi"ii t|t" transaction
accordingly as per the payment. mode preferred. Afte; the request has"ni been processed, lClCl gank wilt
encrypt the response using ctient's pubtic key certificate and post it
back. Ctient witt use their
corresponding private key certificate to decrypL the response received.

These certificate fites are avaitabte with third party vendors. A setf-signed
certificate for UAT is
acceptabte, but for live environments a CA signed one is mandatory.

16,what are the details provided by rcrcr Bank after the configuration
is compreted?
Ans: we provide the API Key & lClCl Bank's Pubtic key certificate
separately for both uAT & production.
17, What is APt Key?

Ans: 'APl Key'is a unique vatue generated for each ctient which is required
to be passed in the header.
18' what is Device'rD, proffle'rD, channel code, account provider, merchant
type, etc. in upr
request packet?
Ans: These are fixed vatues which are generated when the ctient
is configured in uAT & production
environment and the same shatt be provided after the configuration.

19.What is BC lD, passcode and r-code in the lMpS request packet?

Ans: These are fixed values which are generated when the
ctient is configured in uAT & production
environment and the same shatt be provided after the configuration.

2O.what is AGGRTD, AGGRNA 4E, coRprD e USERTD in the NEFT & RTGS request packet?
Ans: These are fixed vatues which are generated when the
ctient is configured in UAT & production
environment and the same shatt be provided after the configuration.

21.What will be the actionable at client,s end against the error

received?
Ans: Actionabte has been mapped against each error codes
in the error code document.
22.What is the ideal response time for Upl transaction?

fnlt F9r UPl, ideatty the finaL status of the transaction will be avaitable within 1g0 secs of
initiating the transaction.

23.What ir the ideal response time for ll ps transaction?

ln:: Fg, IMPS, ideatty the final status of the transaction witt be availabte
initiating the within 1g0 secs of
transaction.

24.What is the limit for number of Upl transactions?

Ans: No transaction timit on volume per day. Can manaqe 2-3
transactions per second.
 flrcrct ernx
25.What is llmit for number of lilPS transactions?
Ans: No transaction limit on votume per day. Can manage 2-3 transactions per second.

26.What is limit for number of NEFT and RTGS?

Ans: No transaction timit on votume per day. Can manage 2'3 transactions per second.

27.Wll NEFT 24X7 be implemented for corporate clients?

Ans: yes. But during 07:00PM to 01:O0AJrA lClCl Banks witt timit the number of transactions to '5' and
consolidate value per user as 2 Lacs. This timit wilt also hold on bank holidays and alternate weekends'

28.What wilt be the status of NEFT transaction, if it is initiated after the NEFT time slot is over for
that day?
Ans: The transaction witt be kept in pending state. No amount sha[[ be debited until the NEFT
window
reopens.

29.What ls 500 error code?

Ans: The request fired in from a non'whitelisted lP.

30.What ts 403 forbldden error code?

Ans: One of the parameters in the request packet isn't correct or the x-priority is incorrect.

31 .What ls 8000 error code?

Ans: The encryption mechanism is incorrect at ctient's end'

32. How to check the encryPtlon-decryption mechanlsm at clients' end?

the corresponding
Ans: Client should encrypt the request using their own public key and decrypt using
private key to understand the mechanism.

33,When will MIS be received?

Ans: The MIS witt be received on T+1 day'

34.Where will the MIS be received?

portal.
Ans: Ctient witt have to downtoad daity transaction Mls from the API developer

35.Will the MIS lnclude falled transactions?

Ans: Optionat. Depends on the clients' requirements.

36.What are the encryption steps for clB registration & Beneficlary ReSistration APls?
Ans: Refer Section 5.2

37.What are the encryption-decryption mechanism for composite API and their resPective
status
check APls?
Ans: Refer Section 5.1

38.When can I use status check of an API and for how many days the status is available
 Orcrct aunk
Ans. You can use the status check API for response not received and for pending scenario. Status check
to be used upto 5 days from the originat transaction day
39. What is the Chargeback request TAT for wrong fund transfer
Ans: within 60 days from the original request.

7.App endix & Modification detai l5Er+atu.q

Chanqes incor porated from Composite API Document y1.11

onwards
1) INTRODUCTION

2.4 Reverse Feed

t*o!{ie-d text: 'For UPl, the finat status of the transaction witt be availabte between
ig0 secs
and T+2 days of initiating the transaction,.

Modified text: 'For IMPS, the final status of the transaction witt be avaitabte
between 180 secs
&. 6 months' of initiating the transaction.,

(.rry exggt tjyeline is subiective to purging actiyity at our end. Hence, it is recommended
check with lclcr team before taking any iction on back doted tronsaction) to

3.2 4096 Bits p ubtic key certificate:

Added text: 'A setf-signed certificate for UAT is acceptabte, but for tive
environments a cA
signed one is mandatory.,

2) 2. API Detaits

'1.5 Input Para meters:

a Addition of 'Provided by lClcl' cotumn for att payment modes

U PI

Removal of MPIN, Ref-lD, Expire-after & Notes from Upl request packet
section as these fietds
are not mandatory
seg-no: This shoutd start with 'rcr and shoutd not have any special characters.

NEFT:

Removal of foltowing optional parameters:

senderName, senderAddress, sendercontactDtts, senderlFSC, senderBankName,
senderBankAddress, senderBankcontactDtts, beneAddress, beneContactDtts,
beneBankName, beneBankAddress, beneBankContactDtts

1.6 am te uest P ckets:

 flrcrct a"nx
. Sampte request packets have been changed for UPl.
. For NEFT & RTGS, details required for UAT testing have been updated.

1 .7 Output Parameters

" NEFT & RTGS out parameter table have been combined
" Sampte response packet for NEFT & RTGS have been updated.
" ln case of success response packet, UTR fietd has been added
". ln case of faiture response packet, ERRORCODE fited has been added.
Sample response code packet have atso been added along with a disctaimer 'Please note, the
sampte response packet mentioned above is standard. But, in some failure cases, parameters
RESioNsECoDE, STATUS & ERRoRCoDE might not appear. RESPoNSE and MESSAGE parameters
witl always appear.'

3) 5 - API Name: Beneficiarv Reeistration

5.1 Description

Added text: ,For ctients with existing ALIAS lD, the defautt configuration for this API witt not
work. Ctient needs to detete their existing ALIAS lD through CIB portat and create a new ALIAS
and
lD simitar to the existing corPorate user tD. For exampte, a ctient has ALIAS lD as 'lClClBank'
corporate user lD as
iBanitz3l5', then client needs to delete the existing ALIAS lD i.e.
itftiS"nL, through CIB portat and create a new ALIAS lD as '8ank12345' which has to be similar
to the corporate user lD.'

Chanqes incor porated fro m Comp osite API Docu ment vl .12 onwards

. VPA Tag added to the UPI request parameter for Nodal account flow
o New Cl-A APts under one nybriO entryptlon, CIB Registration, Bene addition, Bene
Validation and
CIB Neft Status
.lMPsstatusAPladdedtochecktheterminatstatusoffinaltransactions

Chanqes incor porate d from Composite API Docu ment v1 .14 onwards
. IMPS and UPl, status and recon360 APls are integrated into comPosite status
. is
Standalone status and imps recon API removed
. change done to IMPS status API with response starting with {"ImpsResponse":

Changes incor porated from Composite API Docume nt vl .16 onwards

. Changes done to comPosite status IMPS&UPI for recon360 API
. chanles done to for what all enor codes IMps 360 ApI can be invoked. I.e. for 11&30 error codes.
. Below changes in draft over status API of NEFT

Original Thxt:

(lFT fund transfer) - composite status API shows the finat response
lclcl to lclcl fund transfer
RGS transaction- Composite status API to be used for checking debit at account
levet and retrieving UTR
number in case of pending transaction.
RGS lncrementaL status- lncrementat API to be used for finat NEFT resPonse

Modified Text:
 Orcrct a"n*
NEFT transaction processing essentiatty takes place in two steps - a) There is a debit in to remittei
account first, b) Followed by transaction getting submitted to RBI for processing with the time lag.

For NEFT status enquiry there are two sets of APls availabte from lClCl bank given below as -
3) NEFT debit confirmation API - Provides the status of the debit in remitter a/c
4) NEFT credit confirmation API - Provides the status of the credit in beneficiary a/c
Status Enquiry -

c. For money transferred to lclCl bank account bene -

For the amount transferred within lClCl bank the remitter needs to onty use the first Apl ie,
Debit conf irmation APl.

The remitter needs to fire thisAPl and if the response received in status fietd
is .,SUCCESS,,
in that case the transaction can be marked as successfutty processed.
For the status received as faiture the same can be maried as faited and
that particutar
transaction can be re-initiated. For any other status remitter shoutd recheck
the status
after 2 hours. This re-check is required to be done onty once. ln case the status
does not
change to a definite success or falture, in that case no further action
is possibte and this
transaction is to be marked as ,pending,.

Att pending transactions are to be reconciled with the remitter

bank statement to ascertain
the finat status of the transaction. ln case of no respective debit is found
the transaction
can be marked a failed & fresh transaction can be re-initiated.
ln case ine Jeoit is present
in the account the transaction can be marked as successfut.

Additionatty, this API can atso be utitized to fetch the UTR number
for the transaction in
case the same is not received with init.iat

d. For money transferred to non lclCl bank account bene _

It is a two-step process to identify the finat status for these transaction.

4' The remitter needs to fire the first API (Debit) and if the response
received in status
fietd is "SUCCESS" onty and onty in that case the remitter shoutd proceed
to step z tisted
betow.

For the status received as faiture the same can be marked

as faited and that particutar
transaction can be re-initiated. For any other status remitter
should recheck the
status after 2 hours. This re-check is required to be done onrt;n;.-;;ase
does not change to a.definite success or faiture, in that
the status
case no rurtner aciion is possibte
and this transaction is to be marked as ,pending,.

Att pending transactions are to be reconcited with the remitter bank

ascertain the final status of the transaction. ln case of no respectiv"
statement to
transaction can be marked a faited & fresh transaction can be
J"uit ir found
the
re-initi.i"o. tn case the
debit is present in the account then the remitter can proceed t; step-i.
 Orcrct errx
5. Under step 2, the remitter shoutd invoke the second API (Credit API) with the requisite
request packet as documented in API document. Once the status is successfulty received
as "amount credited to beneficiary" transaction can be marked as successfut.

6. lt is possibte that in some scenarios the status is received as "posted to RBl". This status
is provided for the transaction which the beneficiary bank has not provided the uttimate
status. ln such a scenario RBI has provisioned for 72 hrs for the beneficiary bank to
update the finat status of the transaction. However, if the status does not change post
72 hrs the remitter can mark these transactions as successful.

. Neft incremental API request packet parameter changed from "UTR" to UTRNUMBER".
. Expected status vatues updated in NEFT incrementat APl-output parameters

New Response added to gate way sample responses:

Response packet of Gateway Failure, common to all payment modes (failure)

(
"success":false,
"errorCode":"997",
"desc.iption":"Note : lnitaite Status check after Some time"
)
Client Name:

Business Use case:

Projected Avg. #
Avg. # Txns./Day: Txns./Day:
Peak # Txns./Day:
Average TPS
Peak TPS
Avg. Monthly Volume:
Avg Quaterly Volume
Avg. Yearly Volume:
 a PLEASEFILL THE FORMIX ELAC( INI(ONL

Bank
CORPORATE API SUITE - Onboarding Form
We are ready if you are!
DETAILS:
'On-Boarding l0

'Account name as per ICORE

'Account Number for credit/debit tunds

'Account Name {To be tn -surepay)

I_-I-E
Cust l0

'IFSC Code

'Contact Name

'Registered Mobite Number

'Registered Emajt lD
.GSTIN

'Account number to debit ch

'Bittinq addresi: Address

City

State

'Tech Person Name {authorized to give tech

detaits)

'Tech Person Contact number

'Tech Person email lD

'Business SPOC (Person authorized to provide

detaiLs on ,icicibank.com

'Businers sPOC Contr<t number

ln tegrati,on
API

I P.ymont Collection othgri

E CIB RcAisvrtlon E P.ymerts tr ecoltection API - With / Without vatid.tion Balance check

lnitaPay ecottection API with vatidation (Meriale hotd) Bank statcment

IMPS f UPI cottection OTP creatlon and valldation

uPt r.0 / uPt 2.0 E cash Deposit ttachine (CDM) API Trade API

Compotitc Pay Crrh E cheque cottectlon Mth vatidatlon(lsurepay E ileneficlrry Management

E nzH tplv p"yment 5FTP ll2H ecoltectlon n eNACH

IPAY API tr Eazypay (Transaction iettlement & refund API) fl Tranmction aterts

I aers
Direct Tax
tr Goods & Service Tax
D Penny orop

'For Composite API onty

Mode of payment : EIuPr EHPS EnfcslHrrf El8€neficiary Registration API EPayment to Registered Beneficiary

Bustness use casb:

I Merchant payment Refund

tr Disbursement
tr Cashback

Other:
 Commercial:

Rate (per
Transactlon Value transaction)
Less than INR 1,000

Eetween INR 1,000 - INR 25,000

Above INR R5. 25,000

'For ecottection With Vatidation Onty

Refund Code :
of payment: Elnrcs - Nrrr ElmPs E Funds Transfer

'For onty
Mode acceptance; Ecasn Etctct ctreque Etctct oo nNon lclcl DD Eoebit Authorization
-
For Tax API blank if
Corp lD (lf applicabte)

User l0 Standard API user creation

Address

Workftow timit for the Uter

UAT lP - Static and Dynamic

Production tP - Static and

STP I blank if
'user lD
I I

Setup/ Product SetuD/ lmDlementation charges Transaction chartes (Define flat or per R5 t000 basls)

7.

4.
For H

SetuD/ lmDlementation charget M.ndate charges (Per mandate) Transaction charges (per transaction)

rTechnical

'UAT lP (Ptease provide comprehensive list of

lPs that wilt be used for integration)

lP {Ptease provide comPrehenlive

list of ired for tive i

.UAT

'Production
URL/ catLback URL
retum URL/ cattback URL
.UAT URL

URL

for SFTP access for IMPS API

Require iupport from lclcl Bank vendor Ev"t Exo

. for development support witl be applicable ar per actuals agreed between cllent and TsP vcndor
TSP chargcs
. rmptemeiiation support will beibmpttmentary tt tetup/ implementauon charSes excecd R5 50000/. p€r setup
ETPEEN
> h.ra6y.r(le t,|t .ll tlj. p.rtLuLR.id hlo.
I / Wa tro. alv6 h tn Arclk tt . @ tu, dkt, dpl.t .d !p-to'd.ta h.ll raracB .nd I / w. he mt d$h.ld my ldomtlon
> r/-ti..rr!.nd6t.rur.bp.dld...yturtldhfo.tudol!tntErCllekUd./lBGo,Cmp.niatxt.!quk
> I / w. .ir.. .r!r, u!.LBt rt tn t EIO !&l ltd. / G.o(D Cod9.nLr tn dtht to EJct any .prli..tbn nthdt prryldlna .ny r..s
'6.m
frc.n tlne to tlna

> I/ w. traw rc.d, und.ntood .!d hd.by ag.. to r.rn! .nd <ondltio.3 tddlrB UE _rrsh r ..r{!ntrn w{th lmt .M Co.titlsE p.n nnitl
to "Grr.^! r.cMt-.d 'CdDo.tt l6t.rn t likht" a dtpl.yld on w.klclb.nk.cdn.d {r.. to.bl& b, tn sm
> I / w. und.Rt d U.t rh. rid r.G ... rol.ct to BBh. r@ tiE to tl@ .,ld I / iE .ar.. to l!.o @6.t8 up.Ltld oa rudr cn nF .rd b. b.!nd by th. l.m - .r. rn lorc. rrcm Utrt lo tm
6@ffit .;np..y, d t^ G.s or Fx{tty/tB not w69Bd Uy th. ctictid tFcrLd b, th. led. L.k of lnd. lrm dnl. to lj l E!.cgt th.t no dlrRlq q . r.{.llv. / E:r r.l.th. (u sp.clat d
R.GE B. ot llnl!) b. p.rri.r ol mtm / 6, r drc.io., fr. F,6plqE ol nlE / 6 or ot r tri3ldi.ry of m / c, d or ttr lEldlry com95y ol rc / 6, d. aututot d b.h.tr oa / lq / toe / 6, d
hol6 i!b.t hta6t, ln ru / c q. roildLry o.ldlnna @.p.ry of c / 6
^tl.(
*h.t4tr, to.ry Flu d ay thtd 9.ny.nd tn oftkntl.l lntm.tlo. th.ll b. @d by 6, tol.ly lo. th. pu,F* @Ptr.d h.r.h.
> I / W. d..l.rc that I / { he h.d m telvaEy p.E..dq{, {nttl.t d q.tat nt / 6 N h.4l / € .G b6.dd<.Ld hratvt n

sd rh.U F!6 rn rhrlt .ot holrt lCEl LDt Lt!, / lE G@p dtp..l6 li.bl. rd 4 or lhb lniomtlon

> ln.& my / @r PA h mt ed.t d io. Mltllt C.sh lls.a.|ffit !.rvL6, Pl..!. updd. tn. ltr a tBtldtd l. th! lCplk.tion

h lnG App{k tbd

> I / W. .;; .Mr. ol ch.ri6 .p9lr<$1. ior b..klnt !dt6 .d r / e! lutlE uu..E rclcr Lnl to dtb( nry / @ [email protected]{r)tm.r6 .ny ch.l6 lo. th. t l(t d r.vk6.
> I / w. tunlr...aE th.an ry.ddtrr6.t / <6rNt!!d L.ntl.. !r. Mrlld by m / 6. I / E.h.ll b. d..a.d rCmt ly tor tEh .ddltl6.l / stml4d lrllltLt
l/ W. hrE r..d tt! lpoltrtlon rm .,t
-/ .E.dE ol.i 6. t.rc rd <qn
> dn ld &.lllq tnk fsllitv.
> U W. n.E @r.r.^yaru ben tn 6.comptls@ ol th..pplt.U. n16/ r.d.tio, auj<,.llc rn l*c tM tlre to tirc, c fond by dE reN 8rr o{ hdL

lani h.3 $. rlSht to d@ th. F..illty.tt r iM,a 6./ u! 1! d.vr' notL..

> t/ !V. .116 .nd !n&.t r- to p.y tlE t/{rs itrx(o ts lq th. S.rvt6 [email protected] by th. lcrcl l.nl b, Rl6t/ar.l TriE .r/<h.qt city.

tu/ E E, r.r.lt ot *n d.bh.

> trw..,.clx., conlth.,ta iyrc $.t. UWc ina6*rna nxl c..t h prtkuLr! ttuln D, m/G .E ruqslr.d b, tl|. $.r.ti.dl lUid.lln6lo€rnlt b$hlrt cmp.nL'..
> Th.r th. dlriha &col]nt d.-r.tl, rqlrt r.d v,trh l(lcl But (tdlJ(,hi th. &lnabd naoto.la .rx, rh.lt r.rCGtlE tr.B.ctlo. !l!nb) n!!.h,,!*M!d:-.-. - . .
.nytnl*th6 $.rard.. o nryls r.q(t.t.
> irw" r,-.tv ilrc.,
-a.rt.k.;.utlEd; En r.* Lrht.d to mk p.yr6t! by d.btrl,a tlf &(Mt e F lh.lnilrctl6.oLlEd ln lh. r.Bth. nt rdld.dd!o!$tErn!dk.tMs
i-* i.O i-iOv.tr- rOctuk uut 6.rdt b. !.urd b, .ny .'n , .Ll .<{o; rrrd Fr{nt to iJch i.qctt n6 lr rEh reqt 6t3 hn. b.a @unt rhr.d.n by..ub..qst t6r*tld d rnttF
"rA
lliE fd purpor.. ot tnll3nltdn| $d tnl!!.cnd nt6 throqn Afl tt vl..

ui.r API *tut..

.rirhi fr.{n non-lohptl.E or br.&h of rE taB h.cln Dv @{or9ti@/brdcn ol.colk 6l. t tt.
> !.t-olr.nd Lr6;

.nd li.bnl9 to *ttt. .ll dbp{t6/ oolldb wilh nry r(rh Joint t.Mt h.ld.a.

ro.mth.riw.rEy !t. nt d.t mlmd!toE5ol.dk rnl of lclcl !.nk.nd/or lt! irdlp.mp.ni.t.

>u\{.u,{.rrrkcth.t.htp.rthi,Etoslrtuc.vti6tE!'lb.t6t{6Nralwtuttrd.lr.,l.dhwlllt'hct'dondood'
lcl€l lsk. c'h€tl tr..n lclcl &'t'
> iri,l;[email protected]*wlUrctdtu.nyslo.m.Levo Bmodlrk tlonbUt.cn [m dd.bn
> iir* a*r.., *rim, !t .rie r[t oc e*n6*a-rmat iiu]c oi paym"r *u * rpart.d
r,...ty
'(M" to @r cGtomr (ttututi rPl svk ) ! &!d rtld Ut rt*tic tnin .d th.$d u pt'ttm rE
comcLt d / d.li{Ea. q' 3ldt'
> l/wi unddt k thrt .Btodrr wllt h. mtlfi.d fit tlllrtidr! ,lU b. @dlpLt d o.tv *. tlt rfl 6 tn|.d'd tm
> Inlti.t d bv lrt or M c6t0rn 6.
t/yb.bo qnen t th.t lctct 8..t wlll b. prord&d d.$ luidr p.h[ to th. Pro.6rna ol ach tr! !.tlon whrd b .r.illt d bv tu. .r.torltf3 d pryEnt !(h tu6.
> iiii i-tir. tr,"r tr. t- lr.lrtb. urd b. hii.t dlnm;'|.Er r. r ; UE *i. dly !r tll. rLy on ar ..cMt 6r

O.oGGilt{ tor t E elFrad Flod. pdrdd

> iiii r"i rcrci r6d. dih|!
b.,* to ,.dld. uE.ddrlqu r.'rt6 oa iv runnt c'x Ptvipr G bt Gatr'w'
"iiii.oi 'n
tyr. rh.ll mt lm pJl ol t. Ft6 t*tn.

To be signed by cuStomer:

For

DATE Authorized Signatory Authorized Signatory

DD (Rubberieal of companY required) (Rubber seat ofcompany required)

Project Plan for relource allocation

Proiect itart date:

Proiect comptetim date: Authorized Signatory

lRubber seaI of comoanv reauired)

Confirmation memorandum to be signed by lclCl lnternal employee

confirm that the application and related do.uments have been executed at
(ptace) by Person riSned below, in my presence
I
in the Apptication form
on the date mentioned betow and verified with customer tignature availabte Mth Bank account. Atl the information