Composite Pay Api

COMPOSITE PAY API
Documentation
Table of Contents
DOCUMENT REVIEW
Date Version Description
14-Jun-2019 0.1 Initial Draft
17-Jun-2019 0.2 CIB API added
18-Jun-2019 0.3 Changed API process flow

01-Jul-2019 0.4 Inclusion of each flow request-response packet.
10-Jul-2019 0.5 UPI Fields Description updated.
17-Jul-2019 0.6 UPI fields addition

25-Jul-2019 0.7 Error Codes Addition- UPI, IMPS, NEFT
30-Jul-2019 0.8 Curl added
01-Aug-2019 0.9 UPI request packet correction

07-Aug-2019 0.10 IMPS API spec update
08-Aug-2019 1.01 IMPS payload changes

12-Aug-2019 1.02 IMPS Tran Inquiry API Added
16-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 Inclusion of RTGS API
31-Dec-2019 1.07 Inclusion of Beneficiary APIs for UPI

02-Mar-2020 1.08 Revision of Error codes & Documentation
08-Mar-2020 1.09 Revision of FAQs
12-Mar-2020 1.10 Updating UPI request packet & introduction part
04-June-2020 1.11 Addition of Addendum – List of changes incorporated in v1.11

06-Aug-2020 1.12 Daily transaction MIS
26-11-2020 1.13 IMPS 360 API, CIB API under hybrid encryption and VPA Tag
addition
12-Dec-2021 1.14 New APIGEE IPs 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

03-Sep-2022 1.18 Added payee-mcc in UPI request, Added new parameter
description for UPI, IMPS & NEFT, Addition of character limit for
request and response packet
Table of Contents
Table of Contents
Table of Contents ........................................................................................................................................ 3
Introduction ................................................................................................................................................. 4
Composite API ............................................................................................................................................. 7
Composite payment API.............................................................................................................................. 8
UPI ............................................................................................................................................................................. 9
Payment ............................................................................................................................................................ 9
Response packet of Gateway Failure .......................................................................................................... 14
Status check under UPI ...................................................................................................................................... 15
IMPS .......................................................................................................................................................... 19
Payment .......................................................................................................................................................... 19
Status check under IMPS................................................................................................................................... 22
NEFT & RTGS ............................................................................................................................................. 27
Payment .......................................................................................................................................................... 28
Status check under NEFT & RTGS............................................................................................................... 33
Incremental status check under NEFT (Credit Status Check) .................................................................. 36
Sample request packet for Composite payments ..................................................................................... 39
Composite payment process .................................................................................................................... 40
1. API Name: CIB Registration ..................................................................................................................... 40
2. API Name: Beneficiary Registration ........................................................................................................ 42
Beneficiary Registration through account & IFSC ........................................................................... 42
Beneficiary Registration through VPA .............................................................................................. 44
3. Steps before final Integration................................................................................................................... 45
ENCRYPTION-DECRYPTION PROCESS - For Composite Payment, Status Check APIs, and CIB APIs . 48
For encryption of request at ICICI: .............................................................................................................. 48
For encryption of response at ICICI: ........................................................................................................... 48
For decryption of response at Client: ......................................................................................................... 48
Steps for Encryption ..................................................................................................................................... 48
Steps for Decryption ..................................................................................................................................... 49
Frequently asked questions....................................................................................................................... 50
APPENDIX.................................................................................................................................................. 57
Changes incorporated from Composite API_Document v1.11 onwards ................................................................. 57
Table of Contents
Introduction
1. Brief:
In today’s digital world, large base of E-commerce companies and Payment Gateway Aggregators
companies are moving towards API based payments and collection solutions and drifting away from
the existing payment solutions which have a manual intervention or multiple hops in processing of
the payments to the beneficiaries In context to this document, we are introducing the “Composite
pay API” that will cater to any of the payout types payments. The umbrella of composite API will also
include the status check API and beneficiary services APIs for Nodal account holding merchants.
Through this, the customer will have all the payment modes in the API with them and would not have
to go into further iterations of integration with the Bank. Currently, IMPS, NEFT, RTGS and UPI are a
part of this API. 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
like IMPS and UPI can also have a fallback option of NEFT or other payment modes once introduced.
The client can also choose to use all or any one mode of payment. The Composite Pay API is hosted
in the API Gateway of ICICI Bank. APIGW will route any request of Composite Pay API to the respective
system of the payment mode depending on the priorities set in the payment request. In the ERP
Banking context, these APIs will be directly integrated into the ERP of the client and the client can
directly carry out the transactions from the ERP. The transaction status will be fed back into the ERP
as response to the fired API (more details given below). The entire maker checker leg is at the
customer’s end without any bank’s platform being involved in the process.
Table of Contents
2. Structure of Payments
1. CIB Registration: This is a mandatory one-time registration API that is required to access the
Beneficiary Registration & Validation API, NEFT and RTGS payment mode APIs. CIB (Corporate
Internet Banking) is the internal data-base in ICICI Bank for composite pay API and hence, for
processing these APIs credentials are required to be created for the client in the CIB database.
2. Beneficiary Registration: This is the first step for merchants holding the Nodal account. After CIB
registration API is fired, this API is required to be fired which shall register beneficiaries on the fly
to the CIB database.
3. Beneficiary 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 client, at the bank’s end the bene
validation service will be called first by APIGW which will check if the bene is registered in the CIB
5 | P a g e database. If the validation is successful, the transaction leg is called which processes
the transaction basis the payment mode. If the validation fails, the transaction is declined. The
client is shown an appropriate error code as response that the beneficiary is not registered and
the transaction is declined. Please note, this beneficiary validation leg will only be enabled for the
Nodal account holding merchants only.
a. *CIB registration API is required for clients who want to access NEFT, RTGS or beneficiary
registration API. **Beneficiary Registration & Validation is mandatory for Nodal account
holding merchants. Please refer the section ‘4. Debits allowed for Nodal account holding
clients’ in this section below.
4. Payments: The composite API will 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.
5. Reverse Feed: The transaction status will be shared as response within the same API call for IMPS
and UPI modes whereas for NEFT and RTGS’ mode actual status of the transactions will be
available once the transaction batch gets processed. After that, the client is required to fire the
status check API which will be provided to the client to fetch the transaction status. These statuses
essentially get captured back again in the ERP of the client against the respective transaction.
a. Please note, even though UPI and IMPS are real-time payment modes, but we recommend
following timeline to our clients:
b. For UPI, the final status of the transaction will be available between 300 secs and T+2 days
of initiating the transaction.
c. For IMPS, the final status of the transaction will be available between 300 secs and T+2
days of initiating the transaction.
d. (*The exact timeline is subjective to purging activity at our end. Hence, it is recommended
to check with ICICI Bank team before taking any action on back dated transaction. Ideally)
6. Status Check: If the client 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. Please note,
until the status is confirmed, the client is not supposed to change the reference number and
reinitiate the transaction.
Table of Contents
3. Technical Pre-requisite required from client’s end:
1. IP Address: The IP needs to be whitelisted at our end to ensure the security.
2. 4096 Bits Public Key Certificate: Composite API will follow encryption and decryption
mechanism to send and receive request & response from client’s end. Every certificate file will
have two components, i.e. Public Key certificate & Private key certificate. Pubic Key Certificates
are used to encrypt and Private key certificates are used to decrypt. The client will use ICICI Bank’s
pubic key certificate and encrypt the payment request. ICICI Bank will decrypt the payment
request using our private key certificate and then process the transaction accordingly as per the
payment mode preferred. After the request has been processed, ICICI Bank will encrypt the
response using client’s public key certificate and post it back. Client will use their corresponding
private key certificate to decrypt the response received. These certificate files are available with
third party vendors. A self-signed certificate for UAT is acceptable, but for live environments a CA
signed one is mandatory
4. Debits allowed for Nodal Account holding clients:

There are three types of debits allowed on nodal account that is:
1. Refunds/Cashback
2. Vendor pay-out
3. Commission
Beneficiary Registration and Validation is a mandatory API when the client wants to use the Nodal
account for Vendor pay-outs only. The flow will be such that the client will first fire the Beneficiary.
Registration API and then include the registered beneficiary details in the composite API request.
Packet and then subsequently fire the composite API. Composite API for Nodal account
merchants is structured in such way that they shall first validate the beneficiary before processing
the payment request.
5. Daily transaction MIS:
Daily transaction MIS will be made available on the API developer portal
(https://developer.icicibank.com). Client is required to register on the API developer portal and

share the User ID with business team. They will be able to download day-wise transaction MIS
for last 15 days.
Path: Home Page > Account > MIS Download

Clients with multiple accounts or merchant IDs can choose to receive a consolidated MIS on one
single User ID or multiple MIS on multiple User ID.
Table of Contents
Composite API
Composite APIs are a design approach to batch API requests sequentially into a single API call. Rather
than multiple round trips to a server, a client can make one API request with a chain of calls and receive
one response.
Several key benefits of incorporating composite API

Efficient banking system
Time & cost efficient
Secured medium of integration
Real-time output mechanism
Leads to increased productivity
Composite API is a future-driven system, which aims to the advancement of the payment system, with
modified payment mechanisms. ICICI offers a wide range of composite APIs, ranging from the payout,
status check, beneficiary registrations, and others.
To read more about composite API, click here
Table of Contents
Composite payment API
This API will be used to make payments including priority orders to identify and conduct the three
types of payment options i.e., UPI, IMPS, and NEFT.
Refer to the flowchart given below, for the process of composite payment API.
Table of Contents
UPI
Unified Payment Interface is an instant real-time payment system, which facilitates inter-bank, peer-to-
peer, and person-to-merchant transactions.
Payment
Point of access
UAT – https://apibankingonesandbox.icicibank.com/api/v1/composite-payment
LIVE – https://apibankingone.icicibank.com/api/v1/composite-payment
Transactional limit: -
Amount (per
Transaction [24*7]
transaction)
Minimum INR.1
Maximum INR.1,00,000
** For Loan disbursement, maximum limit is Rs. 2,00,000.
Input
Header
Input Provided by
Description Mandatory value
Parameter ICICI
‘API Key’ is a unique value generated
for each client. Key will be provided to
apikey the merchant during onboarding and Yes Mandatory
same needs to be used for all further
transactions.
This value states the priority order for

x-priority the mode of payment. Yes Mandatory
FOR UPI, x-priority = “1000”
Body
Input
parameter & Provided by
Description ICICI Mandatory value
type (maximum
(Yes/No)
character)
Device-ID This is a Unique device Token, which
should be unique per channel user. This Yes Mandatory
[ String (255)]
will be created during registration and
Table of Contents
Note : remitter is the sender
same will be provided to the merchant

by ICICI Bank.
Mobile Number of the remitter. Mobile

Mobile Number
number which was provided during Yes Mandatory
[Number (10)]
onboarding should be used.
channel-code For composite pay merchants, value of

Yes Mandatory
[String (15)] channel code should be “MICICI”.
profile-id Profile ID gets created during onboarding Yes

Mandatory
[String (10)] and same will be shared to the merchant
Random sequence number needs to be

generated by user which should be
seq-no unique starting with ICI and without any
No Mandatory
[String (35)] special character. Merchant should keep
the sequence number handy to check
the transaction status.
account-number No (Doubt)
Account number of the remitter / sender Conditional
[Number (35)]
use-default-acc Yes
Value of “D” needs to be passed. Mandatory
[Character (1)]
account-type Yes
Account type of the sender to be passed Optional
[String (20)]
payee-va Beneficiary VPA to be passed in this

No Mandatory
[String (225)] field.
payer-va Add the Sender’s VPA to be passed in

No Mandatory
[String (225)] this field.
The column carries the total amount

which is expected to be sent by the
amount No
remitter. Mandatory
[Number (14)]
Example: - 15,000.00 [the amount must
have value until two decimals]
pre-approved Yes
Value of “P” to be passed Mandatory
[Character (1)]
default-debit Yes
Value of “N” to be passed Mandatory
[Character (1)]
default-credit Yes
Value of “N” to be passed Mandatory
[Character (1)]
Table of Contents
txn-type Value of ‘merchantToPersonPay’ to be Yes
Mandatory
[String (50)] passed
This column is for the reference, which

remarks
involves any sort of remark involved with No
[String (50)] the transaction. This should not contain Mandatory
any special character. Maximum
character limit is 50.
MCC [Merchant Category Code] refers to

mcc the four-digit number used by NPCI to Yes
Mandatory
[Number (4)] categorize the businesses. The Payer
Merchants MCC code should be passed.
merchant-type Yes
Value of ‘ENTITY’ to be passed Mandatory
[String (50)]
The CorpID of the corporate needs to be

crpID passed. Yes Conditional
[String] [mandatory for only nodal account
holder]
SMS Corporate User ID

userID Yes
[mandatory for only nodal account Conditional
[String]
holder]
Aggregator ID
aggrId Yes
[mandatory for only nodal account Conditional
[String]
holder]
Update Request Number is a unique

urn number assigned during CIB registration No
Conditional
[String] [Mandatory for only nodal account
holder].
This value column will consist of any of

global- address- the following values, pass the
type appropriate values as it is.
Yes
MOBILEMMID ,ACCOUNTIFSC, AADHAR Conditional
[String (20)] NUMBER
Required to be passed only if a payment

to Account + IFSC is done
payee-account This column will hold value in No

correspondence to the account number Conditional
[String (20)] of the beneficiary or the receiver
payee-IFSC No
Add beneficiary bank IFSC code here Conditional
[String (11)]
Table of Contents
VPA Yes
Should be same as Payee ‘VPA”. Conditional
[String (225)] (Doubt)
Initiation mode 00=Default, 01=QR

Code, 02= Secure QR Code, 03=Bharat
initiation-mode QR Code, 04=intent, 05=Secure Intent,
[Numeric (02)] 06=NFC, 07=BLE(Bluetooth),
Yes Conditional
08=UHF(Ultra High Frequency),
09=Aadhaar, 10=SDK, 11=UPI-Mandate, (Doubt)
12=FIR(Foreign Inward Remittance),
13=QR Mandate, 14=BBPS
The purpose field is used especially for

SEBI txn 00-Default, 01=SEBI, 02=AMC,
Purpose
03=Travel, 04= Hospitality, 05=Hospital, Yes Conditional
[Numeric (02)]
06=Telecom, 07=insurance,
08=Education, 09=Gifting,10=Other (Doubt)
Reference number
Mandatory for making credit card and
ref-id QR payments
TxnID to be passed for CC payouts and Yes Conditional
[String(35)]
QR codes. Ref-id should be fetched from
the QR wherever it is available in the QR.
Maximum limit is 35 characters.
payee-mcc If payout is done to a merchant, the MCC
No Optional
[Number][4] of the beneficiary needs to be passed
This provides the preferred currency in

which the company wishes to conduct
currency the transaction. Yes
Optional
[String (3)] This is an optional input because, if there
is no special mention the default INR will
be used for payment.
Table of Contents
A Sample request packet for UPI Transaction
Header apikey = ‘-----------'
x-priority = ’1000’
Body {
"mobile": "7000000023",
"device-id": "190160190160190160190160",
"seq-no": "5DC866EA6ADC427",
"account-provider": "74",
"payee-va": "testo1@icici",
"payer-va": "uattesting0014@icici",
"profile-id": "2995692",
"amount": "1.00",
"pre-approved": "P",
"use-default-acc": "D",
"default-debit": "N",
"default-credit": "N",
"payee-name": "MEHUL",
"mcc": "6011",
"merchant-type": "ENTITY",
"txn-type": "merchantToPersonPay",
"channel-code": "MICICI",
"remarks": "none"
"crpId”: "API3",
"aggrID": "AGGR0008",
"userID": "USER2",
“vpa”:” testo1@icici”
"payee-mcc": "6511",
}
* Above request packet can be directly used on UAT for testing purpose.
Output
Output parameters &
Description
type
This value of the output refers to the status of the transaction –

Success [Boolean]
success/failure
Response [Number] Response code
This value refers to the transactions status message –

Message [String]
successful/failure(reason).
BankRRN [String] It is a unique 12-digit number used to refer to a particular transaction.
UpiTranlogId [String] Internal ID generated on the Switch.
Table of Contents
UserProfile [String] Denotes profile ID of the user.
SeqNo [Number] seq-no input parameter will be echoed back.
MobileAppData value will be always Json based “STRING" (JSON –

MobileAppData [String]
Stringified JSON.)
This is the response code populated by the Payer. For successful

PayerRespCode transactions or for transactions with no issue at the Payer side, this field
will be blank
This is the response code populated by the Payer. For successful

PayeeRespCode transactions or for transactions with no issue at the Payee side, this field
will be blank
This is the response code populated by the Payee at the time of credit
PayeeRevRespCode
reversal. For all other cases, this will be blank.
This is the response code populated by the Payer at the time of debit
PayerRevRespCode
reversal. For all other cases, this will be blank.
A Sample response packet for UPI transaction

Success Failure
{ {
"success": true, "success" : true,
"response": "0", "response" : "39",
"message": "Transaction Successful", "message" : "duplicate seq no from channel",
"BankRRN": "821911303721", "BankRRN" : "44564564564",
"UpiTranlogId": "1275303721", "UpiTranlogId" : "115151",
"UserProfile": "15980666",
"UserProfile" : "11481217",
"SeqNo":ICI820f8967824f4fddb9d11e77566a", "SeqNo": ICIa978816e9f689791fd35430da6b",
"MobileAppData": "SUCCESS",
"MobileAppData" : "",
"PayerRespCode": "00", "PayerRespCode": "00",
"PayeeRespCode": "00" , "PayeeRespCode": "00"
"PayerRevRespCode": "00", "PayerRevRespCode": "00",
"PayeeRevRespCode": "00" "PayeeRevRespCode": "00"
} }
Response packet of Gateway Failure

{
"success":false,
"errorCode":"997",
"description":"Note : Initaite Status check after Some time"
}
Table of Contents
Status check under UPI
Point of access
UAT – https://apibankingonesandbox.icicibank.com/api/v1/composite-status
LIVE – https://apibankingone.icicibank.com/api/v1/composite-status
Input
Header
Input
Description Provided by ICICI Mandatory value
parameter
‘API Key’ is a unique value
apikey Yes Mandatory
generated for each client
This value states the priority

order for the mode of
x-priority payment. Yes Mandatory
FOR UPI, x-priority =
“1000”
Body
Input parameter &
type (maximum Description Mandatory value
character)
This is a Unique device Token, which should be
device-id unique per channel user. This will be created
Mandatory
[String (255)] during registration and same will be provided to
the merchant by ICICI Bank.
mobile
Mobile Number of the Merchant (Sender) Mandatory
[Number (10)]
Random sequence number needs to be

seq-no generated by user which should be unique
starting with ICI and without any special Mandatory
[ String (35)] character. Merchant should keep this sequence
number to check the transaction status.
channel-code
Value of “MICICI” needs to be passed Mandatory
[ String (15)]
profile-id Profile ID gets created during onboarding and

Mandatory
[String (10)] same will be shared to the merchant
Table of Contents
ori-seq-no Seq No of the original transaction for which the
Mandatory
[String (35)] status needs to be checked.
Date [Date
Date when the transaction was initiated Mandatory
(MM/DD/YYYY)]
Fixed value “Y” or “N”

For Value “N,” API will be routed to status API,
API will fetch the status available over switch
recon360 [String(1)] For value “Y,” API will be routed to Recon API for Mandatory
knowing the Deemed approved or pending
transaction status
Pass this field as “N” for normal status check

enquiry and “Y” for recon 360.
A Sample request packet for UPI

UPI status enquiry UPI Recon Status enquire
{
{
"date": "02/22/2021",
"date": "02/22/2021",
"recon360": "Y",
"recon360": "N",
"seq-no":"Unique id to be sent",
"seq-no": "Unique id to be sent",
"ori-seq-no":"SBIbb8319eef7c74f16aa8cd2b0",
"ori-seq-no":"ICIf5DfdC8c6ddgdcfddfdffdfhf2",
"mobile":"9956979792",
"mobile":"9956979792",
"profile-id":"3239272",
"profile-id":"3239272",
"device-id":"19ee1bee5d349d11"
"device-id":"19ee1bee5d349d11"
}
}
Output
Output parameter & type Description
UPI status API response

Success [String] Denotes if service all has successfully completed
This value refers to the code corresponding to the response of the

Response [Number]
initiated transaction.
Message [String] Response code description message
The Bank reference number of the transaction. This needs to be

BankRRN [String]
kept handy in case of any disputes
Table of Contents
UpiTranlogId [String] The Transaction ID generated by Switch.
UserProfile [String] Profile Id of the user.
Denotes current transaction status of the RRN. This is the field

MobileAppData [String] which needs to be referred, for seeking final transaction status of
original transaction.
SeqNo.[String] Seq-no input parameter will be echoed back.
Recon 360 API response

PayeeAccount [Numeric] Beneficiary account number
TransactionType
Default value as PAY for UPI payouts
[Alphanumeric]
PayeeIFSC [Alphanumeric] IFSC of the payee(sender) account
OriginatingChannel [Alpha] Default value “ UPI.NPCI”
OriginalTransactionStatus
Original transaction status
[Alpha]
PayeeName [Alpha] Payee name
PayerIFSC [ Alphanumeric] Payer IFSC
PayerName [Alpha] Payer name
PayerVPA [ Alphanumeric] Payer VPA
MerchantID [ Alphanumeric] Merchant ID
PayeeVPA [ Alphanumeric] Payee VPA
RRN [Numeric] RRN
TransactionAmount [Numeric] Transaction Amount
PayerAccountNumber
Payer Account Number
[Numeric]
DateTimeStatusChange
Date and Time of Status Change
[Alphanumeric]
Current Transaction Status i.e the updated transaction status of

Original transaction
Success responses: Credit confirmation received, Success,

Completed
CurrentTransactionStatus
[ Alphanumeric] Failure response: Failed, Returned received, Customer Reversed
Pending response: Deemed approved, Suspect, Timeout, Initiated

OriginalTransactionStatus needs to be referred if the
CurrentTransactionStatus field is blank
SequenceNumber
Original sequence number
[Alphanumeric]
Table of Contents
IRC[Numeric] IRC
DisplayMessage
Display Message on API call
[ Alphanumeric]
OriginalTransactionDateTime
Original Transaction Date and Time
[ Alphanumeric]
A Sample response packet for UPI status check

UPI status enquiry UPI Recon360 status
{ {"PayeeAccount": "XXXXX7639",
"success": true, "TransactionType": "PAY",
"response": "0", "PayeeIFSC": "SBIN0003160",
"message": "Transaction Successful", "OriginatingChannel": "UPI.NPCI",
"BankRRN": "104714151385", "OriginalTransactionStatus": "Deemed Approved",
"UpiTranlogId": "304844161", "PayeeName": "Mr S VIMALAN",
"UserProfile": "2996298", "PayerIFSC": "",
"SeqNo": "123", "PayerName": "Vignesh .",
"MobileAppData": "PayerVPA": "vignesh18895@oksbi",
{ "MerchantID": "SBIbb8319eef7c74f16a8c9240552d2b0",
"original-txn-rrn":106719317736, "PayeeVPA": "vimalan281096@okicici",
"original-txn-response-code": 0, "RRN": "000320706502",
"original-txn-message": "SUCCESS",
"TransactionAmount": "500",
“npci-resp-code”:,
“payee-vpa:"", "PayerAccountNumber": "XXXXXXXXXXXX976",
“payer-account:"", "DateTimeStatusChange": "2020-0129 15:14:32.0",
“payer-account-type:"", "CurrentTransactionStatus": "Credit Confirmation
“payer-ifsc:"", Received",
“payer-remarks:"Test" "SequenceNumber": "SBIbb8319eef7c74
}
f16aa8c92640552d2b0",
"PayerRespCode": "00",
"IRC": "0000",
"PayeeRespCode": "00"
} "DisplayMessage": "Success. 223813”
"OriginalTransactionDateTime":
"2020-01-03 20:38:48.0"
}
Additional information for Response packet

 Client has to pass the “N” value in the recon360 tag to get the UPI transaction status response
and for Recon360 the value to be passed is “Y”
 Client will receive two different responses for status and UPI360
 Recon360 to be used for pending cases post using the status API and on T+2 working days of
the original transactions.
 Last 5 days' transaction status will be present over UPI status inquiry at any point in time.
Table of Contents
IMPS
Immediate Payment Service [IMPS], is a service which allows fund transfers within banks across India,
in a cost & time efficient manner.
Payment
Point of access
Transaction [24*7] Amount (per

transaction)
Minimum Rs.1
Maximum Rs.5,00,000
Input
Header
Input Provided by
parameter ICICI

payment.
x-priority Yes Mandatory
FOR IMPS,
x-priority = “0100”
Body
Input parameter & Provided
Description
type (maximum by ICICI Mandatory value
character) (Yes/No)
localTxnDtTime Transaction Date & Time
No Mandatory
[String] (YYYYMMDDHHmmss)
beneAccNo
Beneficiary Account Number No Mandatory
[Number (35)]
beneIFSC
Beneficiary bank’s IFSC Code- No Mandatory
[String (11)]
amount
Transaction amount to be transferred No Mandatory
[Number(14)]
Table of Contents
Transaction Reference Number that
tranRefNo uniquely identifies the transaction at BC
No Mandatory
[String] end. Unique number should be entered by
the user
paymentRef Transaction Info, will be send in NPCI

No Mandatory
[String (50)] message
senderName Remitter’s Name. This will be used in the

No Mandatory
[String (20)] message send to NPCI
mobile
Remitter Mobile number No Mandatory
[Number(10)]
retailerCode [String] Value of “rcode” to be passed Yes Mandatory
PassCode been generated by IMPS ans

passCode [String] Yes Mandatory
provided by ICICI during onboarding.
bcID [String] Merchant’s BCID Yes Mandatory
Corporate ID
crpId [String] Yes Conditional
(mandatory for Nodal account)
SMS Corporate User

crpUsr [String] Yes Conditional
(mandatory for Nodal account)
aggrId [String (100)] Aggregator ID Yes Mandatory
A Sample request packet for IMPS transaction
Body {
"localTxnDtTime":"20190808161038",
"beneAccNo": "001700000004",
"beneIFSC": "HDFC9229154",
"amount":"287.00",
"tranRefNo":"1236456",
"paymentRef": "FTTransferP2A",
"senderName": "Ram Singh",
"mobile":"9999988888",
"retailerCode": "rcode",
"passCode": "447c4524c9074b8c97e3a3c40ca7458d",
"bcID": "IBCKer00055",
"crpId": "CIBNEXT",
"crpUsr": "BALAKIRAN"
"aggrId": " AGGRID"
}
Table of Contents
* Above request packet can be directly used on UAT for testing purpose.
Output
Output parameter & type Description

Response [String] ActCode Description
ActCode [String] ActCode Value
TranRefNo [Number] Transaction reference no.
BankRRN [String Bank Transaction Reference Number
BeneName [String] Beneficiary Name
A Sample response packet for IMPS transaction

Success Failure
{ {
"success": true, "success": false,

"Response": "Transaction "ActCodeDesc": "Duplicate
Successful", transaction",
"ActCode": "0", "ActCode": "094",
"TranRefNo": "1238456", "TranRefNo": "803112626398"
"BankRRN": "922019796797", }
"BeneName": "BENE & CUSTOMER NA"
}

{
"success":false,
"errorCode":"997",
}
Table of Contents
Status check under IMPS
Point of access
Input
Header
Input
parameter

x-priority payment. FOR IMPS, Yes Mandatory
Body
Input parameter
& type
Transaction Reference Number that
transRefNo
uniquely identifies the transaction at Mandatory
[Number]
beneficiary end.
Passcode [String] PassCode been generated by IMPS Mandatory
Merchant’s BCID. BCID will be provided to

bcID [String] Mandatory
the merchants during onboarding.
Date [Date
Date of the transaction initiated Mandatory
(MM/DD/YYYY)]
Channel-code Channel code. For IMPS, value should be

Conditional
[Alphanumeric(2)] “BC”.
Fixed value, “Y” or “N,” for which, ‘N’ will

route towards the status API, whereas ‘Y,’
recon360
will route towards Recon 360. Value should Mandatary
[String(1)]
be “N” for normal status check and “Y” for
Recon 360 API.
Table of Contents
A Sample request packet for IMPS status check
IMPS Status enquiry request packet IMPS recon 360 request packet:
{ {
"transRefNo": "134255", "date":"02/16/2021",

"passCode": "recon360":"Y",
"3f4dbbdad1a241bca994339c0d3f3efd", "transRefNo ": "8442310086",
"bcID": "IBCFli00044" }
"recon360":"N",
“date”:” 02/16/2021”
}
Additional information for Request packet
 Client has to pass “N” value in recon360 tag to get the IMPS transaction status response and
for Recon360 the value to be passed is “Y”
 Recon360 to be used for error codes 11&30 post using the status API and on T+2 calendar
days of the original transactions.
Output
Output value & type (maximum Description

character)
IMPS status API response
Response code of the API. Response code "0" indicates the

ActCode[Number]
success response.
Response [String] Transaction Response
BankRRN [Number] Bank RRN number
BeneName[String] Beneficiary Name
Transaction Reference Number that uniquely identifies the

TranRefNo[Number]
transaction at BC end
PaymentRef [String] Payment Reference
TranDateTime [Date] Transaction Date and time
Amount [Number] Amount
BeneMMID [Number] Beneficary MMID
BeneMobile[Number] Beneficiary Mobile Number
BeneAccNo [Number] Beneficiary Account Number
BeneIFSC [String] Beneficiary IFSC
RemMobile[Number] Sender Mobile Number
Table of Contents
RemName [String] Sender Name
Retailer Code
RetailerCode [String]
Recon 360 API response
Transaction Reference Number that uniquely identifies the

TranRefNo [Number]
transaction at BC end
PaymentRef [String] Payment Reference
Display Message[String] Transaction original status
RRN [Number] Bank RRN number
OriginalTransactionStatus [Number] Original transaction status
Current Transaction Status/updated transaction status
Success responses: Credit confirmation received, Success,

Completed
CurrentTransactionStatus [ String]
Failure responses: Failed, Returned received, customer
reversed.
Pending responses: Deemed approved, Suspect, Timeout
OriginalTransactionDateTime [String] DD/MM/YYYY
TransactionAmount [ Number] Transaction amount
BeneficiaryName [ String] Beneficiary name
BeneficiaryAccountNumber[Number] Beneficiary Account number
BeneficiaryMobileNumber [Number] Beneficiary Mobile number
BeneficiaryAadharNumber [String] Beneficiary Aadhar number
BeneficiaryIFSC [String] Beneficiary IFSC
Remitter Name [Alphanumeric (50)] Remitter name
RemitterAccountNumber [Numeric] Remitter Account Number
Table of Contents
A Sample response packet for IMPS status check
IMPS Status enquiry request packet IMPS recon 360 request packet:
{ {
"ActCode":"11", "recon-api-response": {
"Response”: “Time out at NPCI", "headers": {
"message-type": 1001,
"BankRRN":
"proc-code": 455002,
"921011806647", "channel-code": "mobile",
"BeneName": "", "stan": "STAN000002",
"TranRefNo": "3247197400487395", "response-code": "0000",
"PaymentRef": "response-message": "Success."
"FTTransferP2A", },
"TranDateTime": "29-07-2019 "parameters”: {
"index": {}
11:37:13",
"id": 0,
"Amount": "2000", "parameter": [
"BeneMMID": "9028001", {
"BeneMobile": "", "name": "BeneficiaryMobileNo",
"BeneAccNo":"06340110001646", "value": {}
"BeneIFSC": "UCBA0000634", },
"RemMobile":"8800683242", {
"name": "RemitterAccountNumber",
"RemName": "ACTASS
"value": "XXXXXXXX090"
TECHNOLOGIES PRIVATE LIMITED", },
"RetailerCode”: “rcode" {
} "name": "BeneficiaryIFSC",
"value": "ABHY00650"
},
{
"name": "OriginatingChannel
",
"value": "Internet"
},
{
"name": "OriginalTrnsactionStatus",
"value": "Suspect"
},
{
"name": "BeneficiaryName",
"value": {}
},
{
"name": "BeneficiarAadharNumber",
"value": {}
},
{
"name": "RRN",
"value": "00381345517"
},
{
"name": "TransactionAmount
",
"value": 1.84
},
Table of Contents
{
"name": "BeneficiaryAcountNumber",
"value": "XXXXXXXXXX2259"
},
{
"name": "MobileNumbr",
"value": 8898526409
},
{
"name": "CurrentTrasactionStatus",
"value": "Credit Confirmation Received"
},
{
"name": "TranRefNo",
"value": 8442310086
},
{
"name": "IRC",
"value": "0091"
},
{
"name": "DisplayMessage",
"value": "Time out at NPCI
"
},
{
"name": "OriginalTrnsactionDateTime,”
"value": "12-FEB2000.00.00"
},
{
"name": "RemitterName",
"value": "Paytm01"
}
]
}
}
}
}
Table of Contents
NEFT & RTGS
NEFT is an electronic payment system developed by RBI, to facilitate the transfer of funds by
customers from one bank to another bank in India. It is a secured, dependable, and efficient system of
funds transfer between banks,
RTGS is a specialist fund transfer method used to make transfers between two domestic banks on a
real-time or gross basis.
Transaction Type – NEFT/RTGS Maximum Transaction count

cumulative limit per
day
Working Day No maximum limit No maximum limit
Non-Working Day Rs10,00,000 No maximum limit
12:00 AM – 1:00 AM
and 2nd & 4th Saturday,
Limits 1:00 AM – 7:00 PM 7:00 PM – 12:00 AM Sunday & Holidays
for that Date (Clubbed)
(post cut off hrs)
NEFT
Existing Workflow
Per Transaction
limit mapped to Maximum 10 Lakh Maximum 10 Lakh
Amount
Corporate
Number of
NA NA NA
transactions
12:00 AM – 1:00 AM 2nd &

and 4th Saturday,
Limits 1:00 AM – 7:00 PM 7:00 PM – 12:00 AM for Sunday &
that Date Holidays
RTGS (post cut off hrs) (Clubbed)
Per Transaction Existing Workflow limit Maximum 1
Maximum 1 Crore
Amount mapped to Corporate Crore
Number of
NA NA NA
transactions
Note: -
1. ICICI to ICICI TPA transaction are available 24*7

2. Non-working days include Saturday, Sunday and all other public holidays. Additionally, daily
07:00 pm to 01:00 am also considered as Non-Working Day.
3. RTGS are not processed on Sundays and Bank holidays. In case the beneficiary bank has a
holiday, the account will be credited on the next business day.
4. Between 7 PM to 12 AM NEFT transactions up to 10 Lakhs can be processed. After that NEFT
initiated transaction will be processed on next working day.
5. Between 12 AM to 1 AM RTGS Transactions will be rejected at CIB end.
Table of Contents
Payment
Point of access
Input
Header
Input
parameter

payment.
FOR NEFT,
x-priority Yes Mandatory
FOR RTGS,
Body
Input parameter Provided by
& type Description
ICICI Mandatory value
(maximum
character) (Yes/No)
NEFT
tranRefNo
Transaction Reference Number No Mandatory
[String (16)]
amount
Transaction Amount No Mandatory
[Number (19)]
senderAcctNo
Sender’s Bank Account No No Mandatory
[Number (35)]
beneAccNo
Beneficiary Account Number No Mandatory
[Number (35)]
beneName
Beneficiary Name No Mandatory
[String (50)]
Table of Contents
Beneficiary Bank IFSC Code. In case of
beneIFSC ICICI Bank, this should be ‘ICIC0000011’
No Mandatory
[String (11)] In case of ICICI Bank enabled cards, this
should be ‘ICIC0001028’
narration1 Narration 1 (Originator of Remittance)

Details of the sender should be No Mandatory
[String (35*4)] mentioned here.
narration2
Narration 2 (Remittance information) No Optional
[String (35*4)]
crpId
This is the Client Id in CIB Yes Mandatory
[String(32)]
crpUsr
SMS Corporate User Yes Mandatory
[String]
aggrId Aggregator ID. Will be provided to who is the merchant

Yes Mandatory
[String (100)] merchant during onboarding
aggrName
Aggregator Name Yes Mandatory
[String(32)]
Same as passed in registration

urn [String (40)] No Mandatory
request by Partner
‘TPA’ for ICICI as beneficiary Banks;
‘RGS’ for other beneficiary banks;
For Virtual A/c payments Txn_type
should be "VAP" and IFSC should be
txnType ICIC0000103, ICIC0000104 &
ICIC0000106 depending on the client Yes Mandatory
[String(3)]
codes created for the service of virtual
account number based collection. This
is communicated during setup of this
service for any client. IMPS & RTGS txn
will not allowed for virtual payments
WORKFLOW_REQ
D Conditional for Nodal account user with
Yes Conditional
PWT flow.
[String(1)]
RTGS
AGGRID Aggregator Id. Provided to the

Yes Mandatory
[String(100)] aggregators by ICICI Bank.
CORPID
Corporation Id. Provided by ICICI bank. Yes Mandatory
[String(32)]
Table of Contents
USERID
User Id Yes Mandatory
[String(32)]
URN URN Number

No Mandatory
[String(40)]
AGGRNAME
[String(32)]
UNIQUEID
Unique Id No Mandatory
[String(40)]
DEBITACC
Debtor Account no. No Mandatory
[Number(34)]
CREDITACC
Creditor Account no. No Mandatory
[Number(34)]
Beneficiary Bank IFSC Code. In case of

IFSC ICICI Bank, this should be ‘ICIC0000011’
No Mandatory
[String(32)] In case of ICICI Bank enabled cards, this
should be ‘ICIC0001028’
AMOUNT
Transaction Amount No Mandatory
[Number(12)]
CURRENCY
Currency in which transaction held Yes Mandatory
[String(3)]
‘TPA’ for ICICI as beneficiary Banks;

‘RTG’ for other banks;
For Virtual A/c payments Txn_type

should be "VAP" and IFSC should be
TXNTYPE ICIC0000103, ICIC0000104 &
ICIC0000106 depending on the client Yes Mandatory
[String(3)]
codes created for the service of virtual
account number based collection. This
is communicated during setup of this
service for any client. IMPS & RTGS txn
will not allowed for virtual payments.
PAYEENAME
Payee name of transaction No Mandatory
[String(280)]
REMARKS
Remark by payee No Mandatory
[String(255)]
WORKFLOW_REQ
D Conditional for Nodal account user with
Yes Conditional
PWT flow
[String(1)]
Table of Contents
A Sample request packet for NEFT transaction
Body {
"tranRefNo": "abc12345",
"amount": "1",
"senderAcctNo": "000451000301", Doubt: no IFSC for sender
"beneAccNo": "000405002777",
"beneName": "Mehul",
"beneIFSC": "SBIN0003060",
"narration1": "Test",
"crpId": " PRACHICIB1",
"crpUsr": " USER3",
"aggrId": " AGGRID",
"urn": "759969775cff4dcc8b8c63402e645da3",
"aggrName": " AGGRNAME"
"txnType": "RGS"
"WORKFLOW_REQD": "N"
}
Please note sample details for UAT testing:
 Debit Account: 000451000301
 Credit Account: 000405002777
 For ICICI as beneficiary bank use IFSC as ICIC0000011 and ‘txnType’ as “TPA” and for Non-ICICI
Beneficiaries use IFSC as DLXB0000092 and ‘txnType’ as “RGS”, virtual accounts “VAP” (IFSC
103,104,106)
 WORKFLOW_REQD is an optional parameter in Nodal account flow for users with transaction
processing is allowed without workflow.
A Sample request packet for RTGS transaction

Body {
"AGGRID": "AGGRID",
"CORPID": " PRACHICIB1",
"USERID": " USER3",
"URN":"7ef3bc0d03ec495b9f5fa320224ce94e",
"AGGRNAME": "AGGRNAME",
"UNIQUEID": "ICI01234",
"DEBITACC": " 000405001611",
"CREDITACC": "000405002777",
Table of Contents
"IFSC": "ICIC0000004",
"AMOUNT": "1.00",
"CURRENCY": "INR",
"TXNTYPE": "RTG",
"PAYEENAME": "ASDAS",
"REMARKS": "Salary for Payroll Jan"
"WORKFLOW_REQD": "N"
}
Output for NEFT & RTGS
Output parameter & type

Description
(maximum character)
Success
REQID [Number] Request Id of transaction
RESPONSE [String(10)] Response message of transaction
STATUS [String] Transaction original status
UNIQUEID [Number] Unique transaction id
URN [Number(40)] URN Number of transaction
UTR [Number(32)] UTR number generated by Bank
Failure
RESPONSE [String(10)] Response message of transaction
ERRORCODE [String] Response message of transaction
STATUS [String(20)] Status of transaction
RESPONSECODE [String] Unique transaction id
MESSAGE [Number] Failure message with URN number of transaction.
A Sample response packet
NEFT RTGS
Success Success
{ {
"URN": "2634AB", "URN": "2634AB",
"STATUS": "SUCCESS", "STATUS": "SUCCESS",
"UNIQUEID": "312342543", "UNIQUEID": "312342543",
"RESPONSE": "SUCCESS", "RESPONSE": "SUCCESS",
"REQID": "275843" "REQID": "275843"
"UTR": "455849" "UTR": "455849"
}
}
Table of Contents
A Sample response packet
NEFT RTGS
Failure Failure
{ {
"RESPONSECODE":"100042", "RESPONSECODE":"100042",
"MESSAGE":"Transaction with reference id "MESSAGE":"Transaction with reference id
346712386 failed during processing, due to 346712386 failed during processing, due to System
System Malfunction", Malfunction",
"STATUS":"FAILURE", "STATUS":"FAILURE",
"ERRORCODE":"106910", "ERRORCODE":"106910",
"RESPONSE":"FAILURE" "RESPONSE":"FAILURE"
} }
** Please note, the sample response packet mentioned above for NEFT & RTGS is standard. But, in
some failure cases, parameters RESPONSECODE, STATUS & ERRORCODE might not appear.
RESPONSE and MESSAGE parameters will always appear.

{
"success":false,
"errorCode":"997",
}
Status check under NEFT & RTGS
NEFT transaction processing takes place in two steps –
a) There is a debit into the remitter account first.
b) Followed by transaction getting submitted to RBI for processing with the time lag.
For NEFT status inquiry there are two sets of APIs available from ICICI 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 ICICI bank account beneficiary –
For the amount transferred within ICICI bank the remitter needs to only use the first API i.e., Debit
confirmation API. The remitter needs to fire this API and if the response received in the status field
“SUCCESS” in that case the transaction can be marked as successfully processed.
For the status received as failure (Response tag value to be a success) the same can be marked as failed
and that particular transaction can be re-initiated. For any other status, the remitter should recheck the
Table of Contents
status after 2 hours. This re-check is required to be done only once. In 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.’
All pending transactions are to be reconciled with the remitter bank statement to ascertain the final status
of the transaction. In case of no respective debit is found the transaction can be marked a failed & fresh
transaction can be re-initiated. In case the debt is present in the account the transaction can be marked
as successful.
Additionally, this API can also 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 ICICI bank account beneficiary–

It is a two-step process to identify the final status of this transaction.
1. The remitter needs to fire the first API (Debit) and if the response received in the status field is
“SUCCESS” only and only in that case the remitter should proceed to step 2 listed below.
For the status received as a failure the same can be marked as failed and that particular transaction
can be re-initiated. For any other status, the remitter should recheck the status after 2 hours. This
re-check is required to be done only once. In 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.’
All pending transactions are to be reconciled with the remitter bank statement to ascertain the
final status of the transaction. In case of no respective debit is found the transaction can be marked
a failed & fresh transaction can be re-initiated. In case the debit is present in the account then the
remitter can proceed to step.
2. Under step 2, the remitter should invoke the second API (Credit API or Incremental status API)
with the requisite request packet as documented in the API documentation. Once the status is
successfully received as “amount credited to beneficiary” the transaction can be marked as
successful.
3. It is possible that in some scenarios the status is received as “posted to RBI.” This status is
provided for the transaction in which the beneficiary bank has not provided the ultimate status
and after 5hrs of the transaction the status would be changed to “paid”. In such a scenario RBI
has provisioned 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
successful.
Point of access
Table of Contents
Input
Header
Input value & Provided

type Description
by ICICI Mandatory value
(maximum
character) (Yes/No)
This value states the priority order for the

x-priority mode of payment. Yes Mandatory
NEFT (0010), RTGS (0001).
AGGRID
Aggregator Id Yes Mandatory
[String(100)]
CORPID
Corporation Id Yes Mandatory
[String(32)]
USERID
[String(32)]
URN
URN Number No Mandatory
[String(40)]
UNIQUEID Unique Id (Pass the value of ‘tranRefNo’ in this

No Mandatory
[String(40)] parameter for NEFT status check)
Output
Output value & type

Description
(maximum character)
URN [Number(40)] URN Number of transaction
STATUS [String(20)] Status of transaction
UNIQUEID [Number(40)] Unique transaction id
Response message of transaction

RESPONSE [String(10]
UTRNUMBER
UTR Number of the transaction
[Number(32)]
 If Response = FAILURE & Status = Pending, please check inquiry API as per message reflected
in the Response.
 If Response = Success & Status = Pending or pending for processing, then the inquiry service
needs to be reinitiated
Table of Contents
 If Response = Success & Status = Success, terminal state is reached and no further action
require
 If Response = Success & Status = Failure, transaction is to be reinitiated.
 In Case of API gateway error where status tag is not available, inquiry service to be reinitiated.
Incremental status check under NEFT (Credit Status Check)
To be used after 30 minutes of the original transaction once the NEFT batch is processed. API gives the
terminal status of transactions for txnType “RGS”
It is mandatory to use status API (Debit Status Check) before firing incremental API
Point of access
UAT – https://apibankingonesandbox.icicibank.com/api/v1/CIBNEFTStatus
LIVE – https://apibankingone.icicibank.com/api/v1/CIBNEFTStatus
Input
Input
parameter & Provided
Description
type by ICICI Mandatory value
(maximum (Yes/No)
character)
AGGRID
[String(100)]
CORPID
[String(32)]
USERID
[String(32)]
UTRNUMBER
UTN Number No Mandatory
[String(32)]
URN
[String(40)]
A Sample request packet for NEFT

Body {
"URN": "2634AB",
"AGGRID": " Cust0XXX ",
"CORPID": "ICICXXXX",
"USERID": "Deepak",
Table of Contents
" UTRNUMBER": "455849"
}
Output
Output value & type

Description
(maximum character)
IF Txn API terminal STATUS is Success & Pending, Then pass same
UTR no in this API to know the real time NEFT status incremental. Status
can be
1. Posted to RBI(At initial state)
2. Amount credited to Beneficiary(After posted to bene bank & amount
credited to bene Account)
STATUS 3. Amount refunded to Remitter(In case of bene details wrong, verified
by bene bank)
[String(32)] 4. Invalid Transaction ID (In case wrong UTR umber is passed)
5. Paid (If transaction is success at ICICI end & we didn’t get
confirmation from bene bank.)
6. Amount refunded to Remitter (If amount is refunded to the remitter;
reasons parameter will indicate the reason for refund)
7. If NEFT transaction is rejected while processing it will be auto
reversed to client’s account within 24 hours (Expected responses-Invalid
IFSC /Error in processing)
When txn terminal status is success and UTR is generated, then pass
UTRNUMBER same UTR no to know the status. If txn status is 'Pending for processing'
due to Authentication pending or NEFT cut off time. In this case After
[Number(32)]
process txn, get the UTR from normal txn inquiry API. Then pass same
UTR no here to know the acctual status
CreditDate At what time amount credited to bene bank account
[String(32)] DD,MM,YYYY HH:MM:SS AM/PM
Response
Success/Failure
[String(10)]
Sample response packet for NEFT/RTGS Status check

Success Failure
{ {
STATUS:"FAILURE",
“STATUS”: “Amount credited to Beneficiary.",
ErrorCode:"999922",
“UTRNUMBER”:"XXXXXXXXXX",
Message: “Invalid Transaction Id.",
“CreditDate”:"DD, MM,YYYY HH:MM:SS
Response: “Failure"
AM/PM",
}
“Response”: “SUCCESS"
}
Table of Contents
When request sent to Bene bank from RBI & ICICI got confirmation from bene bank about
Amount credited
{
STATUS:"Amount credited to Beneficiary.",
UTRNUMBER:"XXXXXXXXXX",
CreditDate:"DD,MM,YYYY HH:MM:SS
AM/PM",
Response:"SUCCESS"
}
When request sent to Bene bank from RBI & credit confirmation not received from bene
bank
{
STATUS:"Paid",
AM/PM",
Response:"SUCCESS"
}
When Amount refunded to Remitter account, Due to Bene bank details found wrong or
wrong packet is posted
{
STATUS:"Amount refunded to Remitter.",
AM/PM",
Response:"SUCCESS"
}
When Txn id or UTR no is not exist

{
STATUS:"FAILURE",
ErrorCode:"999922",
Message:"Invalid Transaction
Id.",
Response:"Failure"
}
Table of Contents
Sample request packet for Composite payments
Below packet demonstrates IMPS as first priority and NEFT as a fall back option.
First priority – IMPS, second priority - NEFT

Header apikey =
x-priority =”0120”
Body {
"localTxnDtTime":"20190808161038",
"beneAccNo": "001700000004",
"beneIFSC": "HDFC9229154",
"amount":"287.00",
"tranRefNo":"1236456",
"paymentRef": "FTTransferP2A",
"senderName":"Ram singh",
"mobile":"99999888888",
"retailerCode": "rcode",
"passCode": "3f4dbbdad1a241bca994339c0d3f3efd",
"bcID": "IBCFli00044",
"tranRefNo": "abc12345",
"amount": "1",
"senderAcctNo": "000405001257",
"beneAccNo": "000451000001",
"beneName": "Mehul",
"beneIFSC": "SBIN0003060",
"narration1": "Test",
"crpId": "PRACHICIB1",
"crpUsr": "ABC",
"aggrId": "AGGR0028",
"urn": "759969775cff4dcc8b8c63402e645da3",
"aggrName": "Abc",
"txnType": "RGS"
}
Table of Contents
Composite payment process
To initiate the composite payout API, the remitter needs to follow up with a procedure, starting from CIB
registration (based on the type of account), beneficiary registration and validation, payment initiation,
and at last the status check.
1. API Name: CIB Registration

This is a single time API, which is required to access NEFT, RTGS, & Beneficiary API
Point of access
UAT – https://apibankingonesandbox.icicibank.com/api/Corporate/CIB/v1/Registration
LIVE – https://apibankingone.icicibank.com/api/Corporate/CIB/v1/Registration
Input
Input
parameter & Provided
Description
type by ICICI Mandatory value
(maximum (Yes/No)
character)
AGGRNAME
[String (32)]
AGGRID
[String(100)]
CORPID
This is the Client Id in CIB Yes Mandatory
[String(32)]
USERID
[String(32)]
URN Number (This should be kept handy and

same should be used in all future requests).
URN
This a unique value that merchant will assign No Mandatory
[String(40)]
to each registration from his end for security
and recon
ALIAS ID
1. Keep ALIASID field empty pass CorpID and

UserID value in respective parameters in case
user has not created ALIASID.
ALIASID
2. If user created Alias id before registration No Mandatory
[String(32)]
then user should pass ALIASID in Registration
API.
3. ALIASID parameters need to be passed in
the request packet even if it is kept empty.
Table of Contents
A Sample request packet for CIB registration
{
"CORPID":"<Corp ID>"
"USERID":"<user id>"
"AGGRNAME":"Aggregator name"
"AGGRID":"Aggregator id"
“URN”:”URN Number”
"BANKID":"ICI"
}
Output
Input parameter & type

Description
(maximum character)
AGGRNAME [String(100)] Aggregator name
AGGRID [String(32)] Aggregator Id
CORPID [String(32)] Corporation Id
USERID [String(32)] User ID
URN [String(40)] URN Number
Response [String(10)] Response
Message [String(255)] Message
Note: please note there can be only Successful registration request or failed.
 While firing the registration request, the user has to user the same Corporate ID
and User ID which he uses for logging into CIB. The user would get a
SUCCESS/FAILURE response along with a message.
 After getting a success response, the user has to login to CIB using his/her
credentials and do a Self-Approval for this request from “Pending on Me” tray to
complete the one time registration process.
 This service will be called by the Partner to register the user at E Banking.
 If the registration already completed E Banking application will provide the
“Registration Already Completed” message to the Partner.
 If registration is complete then SUCCESS message would be sent to the Partner.
 The registration request will stay in E-Banking for further self-approval
Table of Contents
2. API Name: Beneficiary Registration
Merchants willing to initiate a transaction using a nodal account need to undertake this step,
compulsorily. Under this step, the merchants need to fire ‘Beneficiary Registration API,’ which will
enable the bank to validate the beneficiary registration to follow up with the final payout request.
There are two approaches to undertaking this step for different payment platforms.
a. Beneficiary Registration through account & IFSC – This process suffices the need for payments
to be initiated under IMPS, NEFT & RTGS modes.
b. Beneficiary Registration API through VPA [Virtual Payment Address] - This process suffices the
need for payments to be initiated under UPI mode.
NOTE –
For clients with an existing ALIAS ID, the default configuration for this API will not work. The
client needs to delete their existing ALIAS ID through the CIB portal and create a new ALIAS
ID like the existing corporate user ID.
For example, if a client has ALIAS ID as ‘ICICIBank’ and corporate user ID as ‘Bank12345’, then
the client needs to delete the existing ALIAS ID i.e., ‘ICICIBank’ through the CIB portal and
create a new ALIAS ID as ‘Bank12345’ which must be like the corporate user ID.
Beneficiary Registration through account & IFSC

Point of access
UAT – https://apibankingonesandbox.icicibank.com/api/Corporate/CIB/v1/BeneAddition
LIVE – https://apibankingone.icicibank.com/api/Corporate/CIB/v1/BeneAddition
Input
Input parameter & Provided

Description
type (maximum by ICICI Mandatory value
character) (Yes/No)
CrpId
Client ID in Corporate Internet Banking. Yes Mandatory
[NVARCHAR2(32)]
CrpUsr Customer ID under Client ID in Corporate

Yes Mandatory
[NVARCHAR2(32)] Internet Banking
BnfName
Beneficiary name. No Mandatory
[ NVARCHAR2 (80)]
Beneficiary Nick name. Unique forevery

request.
BnfNickName
No Mandatory
[ NVARCHAR2 (80)]
Table of Contents
BnfAccNo
Beneficiary Account number No Mandatory
[NVARCHAR2 (32)]
PayeeType Client needs to pass respective Payee

type for bene registration 'O' for other No Mandatory
[CHAR (1)] banks & 'W' for within bank WIB. Y
IFSC
Indian Financial System Code. No Mandatory
[NVARCHAR2 (32)]
AGGR_ID ID of the partner to be provided and

Yes Mandatory
[NVARCHAR2 (100)] hardcoded by ICICI Bank.
This a unique value that partner will

URN [NVARCHAR2
assign to each registration from his end No Mandatory
(40)]
for security and recon.
A Sample request packet for Beneficiary registration through account & IFSC
{
"CrpId": "PRACHICIB1",
"CrpUsr":"USER4",
"BnfName": "AnshumanMishra",
"BnfNickName": "Ansh",
"BnfAccNo":"000405001257",
"PayeeType": "W",
"IFSC": "ICIC0000011",
"AGGR_ID": "AGGR0002",
"URN: "3kCy4sPuSqDNi4kggXJIoE568221"
}
Output
Input parameter & type Description

Message
Status message of request
[NVARCHAR(255)]
Response
Response SUCCESS OR FAILURE
[NVARCHAR(10)]
Errorcode
Error Code
[Number (40)]
BNF_ID [Number (10)] Beneficiary ID
Table of Contents
A Sample response packet for Beneficiary registration through account & IFSC
SUCCESS FAILURE
{
BNF_ID:"4836", {
Message: "You may not be able to make Fund Message: "Invalid Corp Id or User Id
transfer immediately with newly added Or Aggregator Id is passed.",
payee, please check payee status before ErrorCode:"9906",
proceeding", Response: "Failure"
Response: "SUCCESS" }
}
Beneficiary Registration through VPA
This API will register beneficiary on the basis of VPA essential for UPI payment mode for Nodal account
holding merchants.
Point of access
UAT – https://apibankingonesandbox.icicibank.com/api/Corporate/CIB/VPA/v1/BeneAddition
LIVE – https://apibankingone.icicibank.com/api/Corporate/CIB/VPA/v1/BeneAddition
Input
Input Provided
Description
parameter & by ICICI Mandatory value
type (Yes/No)
AGGRID
[String]
CORPID
[String]
USERID
[String]
URN
[String]
VPA
ALIAS ID Yes Mandatory
[String]
Table of Contents
A Sample request packet for Beneficiary registration through VPA
{
"AGGRID": "PRACHICIB1",
"CORPID":"USER4",
"USERID": "AnshumanMishra",
"URN": "1234567
"VPA": "test0@icici",
}
Output
Input value & type Description

Message [String] Status message of request
Response [String] Response SUCCESS OR FAILURE
Errorcode [String] Error Code
A Sample response packet for Beneficiary registration through VPA

SUCCESS FAILURE
{ {
BNF_ID:"4836", Message: “Invalid Corp Id or User
Message: “You may not be able to make fund Id Or Aggregator Id is
transfer immediately with newly added payee, passed.",
please check payee status before proceeding", ErrorCode:"9906",
Response: “SUCCESS" Response: “Failure"
} }
3. Steps before final Integration
Things to be considered before moving forward with this step

 The one-time CIB registration is completed successfully
 The beneficiary is registered and validated by using the above-mentioned API
 The remitter must hold a merchant or a nodal account with the bank.
 All the necessary documents are being submitted and processed by the firm
 The details mentioned in the request package for initiating the transaction are thoroughly
analyzed.
Table of Contents
Encryption & decryption
For the purpose of maintaining security of APIs initiated through composite API, it is very
important for the APIs to be sent between the merchant and the bank in an encrypted form.
Thus it is required for the merchant to initiate the API in an encrypted form using their public
key. The bank will also be sending the response also in the encrypted form and the merchants
need to decrypt the same using their private key at their side and take the action accordingly.
Input value & type Description Provided by ICICI

Mandatory value
(maximum character) (Yes/No)
Unique identifier
requestId for the request.
-- Optional
[String (64)] Not being stored
at any level.
Service Name;
service type Identifying the
-- Mandatory
[String] backend service
name
One-time use AES

key encrypted by
the Client's public
encryptedKey [String.
key. Requirement
Base64- encoded data -- Mandatory
is for a 128-bit key
(case insensitive)]
(with 256-bit key
supported as an
option).
Value: NONE, Meaning:

RSA/ECB/PKCS1 is used
for Asymmetric
Describes the
Encryption Value :
oaepHashingAlgor ithm algorithm used for
SHA1, Meaning :
Asymmetric Mandatory
[String (6)] RSA/NONE/
Encryption of one
OAEPWithSHA1AndMGF
time AES key.
1Padding OR RSA/ECB/
OAEPWithSHA1AndMGF
1Padding
Yes, if IV is not part of

encrypted data itself.
The initialization Leave blank otherwise. For
Iv [String. Base64- vector used when Exactly 16 bytes actual the response data
encoded data encrypting data value to match the block encrypted at ICICI end, IV
(caseinsensitive) (24)] using the one-time size will always be part of
use AES key. encryptedData itself and it
is randomly generated for
each request. Can be
retrieved by Client by
Table of Contents
retrieving the first 16 bytes
of Base64 decoded
encryptedData
Contains the
encrypted
dataPayload
object containing
the business
information.
encryptedData Encrypted by the
[String. Base64- ephemeral AES
-- Mandatory
encoded data key using
(caseinsensitive)] AES/CBC/PKCS5Pa
dding. Sample
unencrypted
object: Please
refer first section
of document for a
sample object.
clientInfo ClientIP or other

-- Optional
[String] information
optionalParam Reserved for

-- Optional
[String] future use
A Sample request packet for Encrypted Request to be sent to Client (JSON):

{
"requestId": "",
"service":
"PaymentApi",
"encryptedKey":
"oG5mU1JJNBuwQaSLKb3wfRZks/cT2Vo2yBNNuqjNHDWEC144WxC8iKqBpJAgq7reFKC4sHNUmNP
RDya1AvmQ7x1L+3EAdEs9FEWNurZuWTvZpk4y7JrGhg0rz9KptBf+JfJUkSMo7NR3Saxel6EYtckkDr
3AGW7WJZmhcEoAMMXRws/hLVmaNHC/3nOjCNqqBd4IOOAzdJh/HADRVI+YAJKT8dE4x9NTl+UX
1zAooWhza+TsWEHfxzQIa7zai7WSa/wiJD3uD7mk5vT1WY/fKJBquCuzM7l35vigDhmb7dLVLuX8VMi
NQrtErWNI0uVaag1jg+uZUtyDSxjPFi5yEpKVVc7+T503IDnCvkCFDygqasDsPL24qOjYk4XavTZvwGuP
AdYNNkVnLzVElEhg4zS2ye+fa/8fZiMt/3fwYeN9dgn9i5R6VOFbXSuZJYPSci9k0oqz73h1nzFtps60rUE
DoGIkGvm9waJU3W78VH5mIdGfGvvJjiKIuVHmi/huzEX9v4w3mW7RDGgmOuKImkqki+XWgyB0JvV
msLdO+cBaym/seZP3+zdfhO9AWSI2tDLD4Vf0jDjzoDSFN2mzUFgHK9mbtbXgvsnReoGqx/KsivzmZ
NLmDmtg8eR4Z9LnLni4rl4OtkDv5y/mxMtL3MBUUUajkw6OS6NnhEG895yo=",
"oaepHashingAlgorithm":"NONE",
Table of Contents
"iv": "",
"encryptedData":"wBJSefFsnJVlobh1cJR553w6Ay6b8/2frCjxvdZ1Bsnxztsul7Ha8lFl4PoZD+IhdlRShW
dKgz3yJYIisGV/KKpyMSY3DILOpbkqEa 0Qq0g=",
"clientInfo": "",
"optionalParam": ""
ENCRYPTION-DECRYPTION PROCESS - For Composite Payment, Status Check APIs, and CIB APIs
For encryption of request at ICICI:
SesionKey = Randomly generated string of length 16 (OR 32).
encryptedKey = Base64Encode (RSA/ECB/PKCS1Encryption (SesionKey,ICICIPubKey.cer))
IV = Initialization Vector- Exactly 16 bytes actual value to match the block size
encryptedData = Base64Encode(AES/CBC/PKCS5Padding(Request,SessionKey, IV))
For encryption of response at ICICI:
encryptedKey= Base64Encode(RSA/ECB/PKCS1Encryption(SesionKey,ClientPubKey.cer))
Session key is nothing but randomly generated string of length 16 (OR 32).
encryptedData = Base64Encode(AES/CBC/PKCS5Padding(Response,SessionKey))
For decryption of response at Client:
IV=getFirst16Bytes(Base64Decode(encryptedData)
SessionKey= Base64Decode(RSA/ECB/PKCS1Decryption(encryptedKey,ClientPrivateKey.p12,))
Session key is nothing but randomly generated string of length 16 (OR 32) .
Response = Base64Decode (AES/CBC/PKCS5Padding Decryption(encryptedData,SessionKey,IV))
OR
Steps for Encryption
Generate 16-digit random number. Say RANDOMNO.
Table of Contents
Encrypt RANDOMNO using RSA/ECB/PKCS1Padding and encode using Base64. Say encryptedKey.
Perform AES/CBC/PKCS5Padding encryption on request payload using RANDOMNO as key and
ivinitialization vector. Say encryptedData.
Now client may choose to send IV in request from one of below two options.
a.) Send Base64 Encoded IV in “iv” tag. (Recommended Approach)
b.) Send IV as a part of encryptedData itself.
bytes[] iv = IV;
bytes[] cipherText = symmetrically encrypted Bytes (step3)
bytes[] concatB = iv + cipherText;
encryptedData = B64Encode(concatB);
Perform AES/CBC/PKCS5Padding encryption on DATA using RANDOMNO as key and Base64encoded
RANDOMNO as IV. Say ENCR_DATA.
Steps for Decryption
Get the IV- Base64 decode the encryptedData and get first 16 bytes and rest is encrypted response.
bytes[] IV= getFirst16Bytes(Base64Decode(encryptedData)
Decrypt encryptedKey using algo (RSA/ECB/PKCS1Padding) and Client’s private key.

Decrypt the response using algo (AES/CBC/PKCS5Padding).
Ignore first 16 bytes of response, as it contains IV.
Table of Contents
Frequently asked questions
COMPOSITE API
S No. QUESTION ANSWER
A single API mechanism that accommodates payments

1 What is composite API? for the top 4 payment methods i.e., UPI, IMPS, NEFT &
RTGS.
To move ahead with the procedure, several documents

are required to be submitted, which are as follow's -
1. Production IP(s)
2. CA-signed 4096 bits public key certificate

What is the basic pre-requisite 3. API application form with commercials
2 to be followed? mentioned.
4. Business requirement form [transaction

volumes]
5. RoI sheet
6. Type of account – nodal/non-nodal

7. Filled UAT sign-off form
The basic steps to be followed can be classified as,

What is the process to be
followed to initiate the CIB registration >> Beneficiary registration >>
3 transaction? Beneficiary Validation >> Payment initiation >> Status
check
BENEFICIARY REGISTRATION API

1 Is Beneficiary Registration API No. It is only mandatory for clients transacting from the
Mandatory? Nodal account
2 How do you do the status check Fire Beneficiary registration API again, and you will
of Beneficiary Registration API? receive a response, ‘Beneficiary already registered.’
3 How much time does Beneficiary Registration API is a real-time API. As soon
beneficiary registration API takes as the API response is received, the Beneficiary is
to register the beneficiaries? registered on the database and the transfer API can be
processed.
Table of Contents
CIB REGISTRATION API
What is CIB registration? This is a one-time API that registers clients on CIB which
1 is our internal system. This is required for clients to use
the Beneficiary registration, NEFT & RTGS APIs.
CIB is a database ensuring the required credentials for

Why should someone use this individual clients to maintain a smooth flow of
API? functioning. This primary stage is a one-time mandatory
2
registration API that is required to access the
Beneficiary Registration & Validation API, NEFT, and
RTGS payment mode APIs
In UAT approval is done at back-end, post firing the

How approval is done for CIB
registration API.
registration in UAT or
3 production. In production, the client must log in the CIB portal,
select connected banking, and approve from pending
approvals.
ENCRYPTION-DECRYPTION PROCESS
How to check the encryption- The client should encrypt the request using their public
1 decryption mechanism at key and decrypt using the corresponding private key to
clients’ end? understand the mechanism.
What are the encryption steps

Please refer ENCRYPTION-DECRYPTION PROCESS - For
2 for CIB registration & Beneficiary
Composite Payment, Status Check APIs, and CIB APIs
Registration APIs?
What is the encryption-

decryption mechanism for Please refer ENCRYPTION-DECRYPTION PROCESS - For
3
Composite API and their Composite Payment, Status Check APIs, and CIB APIs
respective status check APIs?
COMPOSITE PAYOUT API
What are several payment There are four platforms currently available under the
1 methods covered under composite payout API system, such as UPI, IMPS, NEFT
Composite payment API? & RTGS.
Yes. It is possible to prioritize more than one payment

Can we prioritize more than one platform in a single request packet.
2 payment platform in a single To do so, avail a unique value of x-priority in headers.
request packet?
Put the value ‘1’ against the preferred payment mode
and the rest all as ‘0’. Therefore, in the case of just UPI,
Table of Contents
IMPS, NEFT & RTGS, x-priority shall be 1000, 0100, 0010
& 0001. Or
To access, more than one mode provides 1,2,3, & 4 as

values corresponding to the place value of each
payment mode.
THOUSANDTH HUNDREDTH TEN’TH ONE’TH
UPI IMPS NEFT RTGS
This value consists of denotation in order of prioritized

platforms. It is a 4-digit input value required to be
provided in the ‘HEADER’ column. The first, second,
third & fourth digit of this value refers to UPI, IMPS,
NEFT & RTGS, respectively.
What is x-priority? Where to For example,

3 avail this value.
Priority Platform “x-priority” input
Only UPI 1000
Only IMPS 0100
Only NEFT 0010
First IMPS, second NEFT 0120
Will the request parameter’s Yes. The request packet needs to include the mandatory
4 change for accessing more than parameters for all the payment modes selected.
one payment mode?
How can we check status of our We have a ‘Status check API,’ which could be used to
5
transaction? check the status of the transaction.
When can I use status check of You can use the status check API for responses not
6 an API and for how many days received and for the pending scenario. Status check to
the status is available? be used up to 5 days from the original transaction day.
Is it mandatory to do status No. The use of this API is dependent on the status of the
7
check after every transaction? final transaction.
What is required from clients’

8 IP addresses & 4096 Bits Public key certificate.
end for testing?
9 Why is IP address required? To maintain security, we whitelist clients IP addresses.
Composite API will follow an encryption and decryption

mechanism to send and receive requests & responses
What is 4096 Bits Public key from the client’s end. Every certificate file will have two
10 certificates? components, i.e., a Public Key certificate & Private key
certificate. Public Key Certificates are used to encrypt,
and Private key certificates are used to decrypt.
Table of Contents
The client will use ICICI Bank’s public key certificate and
encrypt the payment request. ICICI Bank will decrypt the
payment request using our private key certificate and
then process the transaction accordingly as per the
payment mode preferred. After the request has been
processed, ICICI Bank will encrypt the response using
the client’s public key certificate and post it back. The
client will use their corresponding private key certificate
to decrypt the response received.
These certificate files are available from third-party

vendors. A self-signed certificate for UAT is acceptable,
but for living environments a CA-signed one is
mandatory.
What are the details provided by

We provide the API Key & ICICI Bank’s Public key
11 ICICI Bank after the configuration
certificate separately for both UAT & production.
is completed?
‘API Key’ is a unique value generated for each client

12 What is API Key?
which is required to be passed in the header.
What will be the actionable at

Actionable has been mapped against each error code in
13 client’s end against the error
the error code document.
received?
PAYMENT PLATFORM – UPI
What is Device-ID, profile-ID,

These are fixed values that are generated when the
channel code, account provider,
1 client is configured in UAT & Production environment
merchant type, etc. in UPI
and the same shall be provided after the configuration.
request packet?
What is the ideal response time For UPI, ideally, the final status of the transaction will be
2
for UPI transaction? available within 180 secs of initiating the transaction.
No transaction limit on volume per day. Can manage 2-3

What is the limit for number of transactions per second.
3
UPI transactions?
Table of Contents
PAYMENT PLATFORM – IMPS
What is BC ID, passcode, and r- These are fixed values that are generated when the
1 code in the IMPS request client is configured in UAT & Production environment
packet? and the same shall be provided after the configuration.
For IMPS, ideally, the final status of the transaction will

What is the ideal response time be available within 180 secs of initiating the transaction.
2
for IMPS transaction?
What is limit for number of IMPS No transaction limit on volume per day. Can manage 2-3
3
transactions? transactions per second.
PAYMENT PLATFORM – NEFT/RTGS
These are fixed values that are generated when the

What is AGGRID, AGGRNAME, client is configured in UAT & Production environment
1 CORPID & USERID in the NEFT & and the same shall be provided after the configuration.
RTGS request packet?
What is limit for number of NEFT No transaction limit on volume per day. Can manage 2-3
2
and RTGS? transactions per second.
Yes. But from 07:00 PM to 01:00 AM ICICI Banks will

Will NEFT 24X7 be implemented limit the number of transactions to ‘5’ and consolidate
3
for corporate clients? value per user as 2 Lacs. This limit will also hold on to
bank holidays and alternate weekends.
What will be the status of NEFT

transaction, if it is initiated after The transaction will be kept in a pending state. No
4
the NEFT time slot is over for amount shall be debited until the NEFT window reopens
that day?
DAILY TRANSACTION – MIS
This is an in-built mechanism that enables excess to the

1 What is MIS?
status records of the initiated transaction.
2 When will MIS be received? The MIS will be received on T+1 day.
The client will have to download daily transaction MIS

3 Where will the MIS be received?
from the API developer portal.
Will the MIS include failed Optional. Depends on the clients’ requirements.
4
transactions?
Table of Contents
ICICI Reconciliation process
Client should treat status sent Yes, Status sent via Original transaction responses or via
through status API call or status status inquiries( including UPI 360 API) should be
1 considered as Source of Truth
in UPI 360 API call as the source
of truth or not?
Since the status change for a deemed transaction is

dependent on beneficiary bank updating the status. The
TAT prescribed by NPCI is T+1. For CLIENT, deemed
approved should be treated at par to Success.
90% DEEMED Approved cases Beneficiary bank update can come after NPCI TAT of T+1
2 should reach FAILED/SUCCESS as well. Such status do change in UPI 360 as per process.
by T+1 calendar days?
Client can approach Bank operations team via their Bank
relationship team to get the updates or raise the deferred
chargebacks.
Final transaction status update is provided by beneficiary

bank and Remitter bank can only influence via raising
deferred chargebacks.
100% transactions should reach
the terminal state by T+2 If there are any cases pending for status update beyond
calendar days through status T+2 calendar days, then Client needs to reach out to the
3
API/360 API? Bank Operations team to get the final status update.
CLIENT needs to check status via status inquiry or UPI
360 API service till T+2 day and then approach their
Bank relationship teams.
If there are any transactions

with “Success” status received CLIENT will reach out to the Bank Operations team via
from status API/360 API calls their Bank relationship team to inform and verify the
and Client receives credit in the reason for this ambiguity. The Client team will update the
4 account statement does this transaction status based on confirmation from the ICICI
indicate that client should mark Bank relationship team.
these cases as failed?
If there are any transactions CLIENT will reach out to the Bank relationship team who
with “Failed” status received in turn will coordinate with Bank Operations team for the
from status API/360 API calls final status and reason for non-reversal of funds towards
5 and Client doesn’t receive credit failed transactions. The Client team will update the
in the account statement till transaction status based on confirmation from ICICI bank.
T+2 days, how client can get
their funds?
Table of Contents
If transactions are in “Success”
Client’s team needs to highlight the cases to the Bank
status and Client receives a
relationship team and in turn they will coordinate with
query from the merchant that
bank Operations team who will engage with NPCI/
their beneficiary customer
6 Beneficiary Banks to verify the credit status to
didn’t receive the money, what
beneficiary. Such confirmation will be relayed back to
is the course of action available
CLIENT by the Bank’s relationship team.
to Client?
Final status is dependent on Beneficiary bank. As per

SLA for clearing payouts that prescribed TAT by NPCI, all such cases needs to be either
breach T+2 TAT from status marked TCC (Credit confirmation) or RET (Failed
API. How long will the ICICI confirmation). Bank Team will raise such cases to NPCI at
7 Issue raised date+1 business working day to facilitate the
Bank relationship team take to
revert back with the final status response to client. Bank’s relationship team would keep
post they are highlighted? the client informed.
Will the payouts be updated Any change in status is in parallel updated in UPI 360 as
automatically by the system or well. However, CLIENT will treat status given by Bank’s
8 will they be manually updated relationship team as final.
post confirmation from the ICICI
team?
Bank’s relationship team would coordinate with bank’s

How will ICICI bank update operations team to check the status of these cases in
CLIENT regarding status of URCS and update to CLIENT at Raised Date + 5 business
9 deferred chargebacks? working day. (Raise Date + 4 days is the TAT given by
NPCI for all deferred chargeback cases)
Table of Contents
APPENDIX
Changes incorporated from Composite API_Document v1.11 onwards
1) 1, INTRODUCTION
2.4 Reverse Feed:
• Modified text: ‘For UPI, the final status of the transaction will be available between 300 secs
and T+2 days of initiating the transaction’.
• Modified text: ‘For IMPS, the final status of the transaction will be available between 300 secs
& 6 months* of initiating the transaction.’
(*The exact timeline is subjective to purging activity at our end . Hence, it is recommended to
check with ICICI team before taking any action on back dated transaction)
3.2 4096 Bits public key certificate:
Added text: ‘A self-signed certificate for UAT is acceptable, but for live environments a CA signed
one is mandatory.’
2) 2. API Details
1.5 Input Parameters:
• Addition of ‘Provided by ICICI’ column for all payment modes
UPI:
• Removal of MPIN, Ref-ID, Expire-after & Notes from UPI request packet section as these
fields are not mandatory
• Seq-no: This should start with ‘ICI’ and should not have any special characters.
NEFT:
• Removal of following optional parameters:

senderName, senderAddress, senderContactDtls, senderIFSC, senderBankName,
senderBankAddress, senderBankContactDtls, beneAddress, beneContactDtls,
beneBankName, beneBankAddress, beneBankContactDtls
1.6 Sample Request Packets:
• Sample request packets have been changed for UPI.

• For NEFT & RTGS, details required for UAT testing have been updated.
1.7 Output Parameters
• NEFT & RTGS out parameter table have been combined
Table of Contents
• Sample response packet for NEFT & RTGS have been updated.
• In case of success response packet, UTR field has been added
• In case of failure response packet, ERRORCODE filed has been added.
• Sample response code packet have also been added along with a disclaimer ‘Please note,
the sample response packet mentioned above is standard. But, in some failure cases,
parameters RESPONSECODE, STATUS & ERRORCODE might not appear. RESPONSE and
MESSAGE parameters will always appear.’
3) 5. API Name: Beneficiary Registration
5.1 Description:
Added text: ‘For clients with existing ALIAS ID, the default configuration for this API will
not work. Client needs to delete their existing ALIAS ID through CIB portal and create a new ALIAS
ID similar to the existing corporate user ID. For example, a client has ALIAS ID as ‘ICICIBank’ and
corporate user ID as ‘Bank12345’, then client needs to delete the existing ALIAS ID i.e. ‘ICICIBank’
through CIB portal and create a new ALIAS ID as ‘Bank12345’ which has to be similar to the
corporate user ID.’
• VPA Tag added to the UPI request parameter for Nodal account flow
• New CIB APIs under one hybrid encryption, CIB Registration, Bene addition, Bene
Validation and CIB Neft Status
• IMPS Status API added to check the terminal status of final transactions
• IMPS and UPI, status and recon360 APIs are integrated into composite status
• Standalone status and imps recon API is removed
• Change done to IMPS status API with response starting with {"ImpsResponse":
• Changes done to composite status IMPS&UPI for recon360 API

• Changes done to for what all error codes IMPS 360 API can be invoked. I.e. for
11&30 error codes.
• Below changes in draft over status API of NEFT
Original Text:
• ICICI to ICICI fund transfer (IFT fund transfer) – Composite status API shows the final
response
• RGS transaction- Composite status API to be used for checking debit at account
level and retrieving UTR number in case of pending transaction.
• RGS Incremental status- Incremental API to be used for final NEFT response
Modified Text:
Table of Contents
 NEFT transaction processing essentially takes place in two steps – a) There is a debit in to
remitter 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 APIs available from ICICI 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 ICICI bank account bene –
For the amount transferred within ICICI bank the remitter needs to only use the first API ie. Debit
confirmation API.
The remitter needs to fire this API and if the response received in status field is “SUCCESS” in that
case the transaction can be marked as successfully processed.
For the status received as failure the same can be marked as failed and that particular 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. In 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’.
final status of the transaction. In case of no respective debit is found the transaction can be marked
a failed & fresh transaction can be re-initiated. In case the debit is present in the account the
transaction can be marked as successful.
Additionally, this API can also be utilized to fetch the UTR number for the transaction in case the
same is not received with initial
d. For money transferred to non ICICI bank account bene –
It is a two-step process to identify the final status for these transaction.
4. The remitter needs to fire the first API (Debit) and if the response received in status field is
“SUCCESS” only and only in that case the remitter should proceed to step 2 listed below.
For the status received as failure the same can be marked as failed and that particular
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. In 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’.
final status of the transaction. In case of no respective debit is found the transaction can be
marked a failed & fresh transaction can be re-initiated. In case the debit is present in the
account then the remitter can proceed to step 2.
5. Under step 2, the remitter should invoke the second API (Credit API) with the requisite
request packet as documented in API document. Once the status is successfully received as
“amount credited to beneficiary“ transaction can be marked as successful.
Table of Contents
6. It is possible that in some scenarios the status is received as “posted to RBI”. This status
is provided for the transaction which the beneficiary bank has not provided the ultimate status.
In 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 successful.
 Neft incremental API request packet parameter changed from “UTR” to UTRNUMBER”.
 Expected status values updated in NEFT incremental API_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",
}
 Recon360 API FAQs added
 Overall change in the format of the document to improve the readability of the same
 Addition of payee-mcc in UPI request
 Addition of character limit for all request and response packet
 Incorporation of few of the common queries in the document
 Modified the description of request packets for merchants
Table of Contents

Composite Pay Api - 1.18

Uploaded by

Copyright:

Available Formats

You might also like

Composite Pay Api - 1.18

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Composite Pay Api - 1.18

Uploaded by

Copyright:

Available Formats

17-Jun-2019 0.2 CIB API added

18-Jun-2019 0.3 Changed API process flow

10-Jul-2019 0.5 UPI Fields Description updated.

17-Jul-2019 0.6 UPI fields addition

30-Jul-2019 0.8 Curl added

01-Aug-2019 0.9 UPI request packet correction

08-Aug-2019 1.01 IMPS payload changes

16-Sep-2019 1.03 Addition Beneficiary Registration API

16-Dec-2019 1.06 Inclusion of RTGS API

31-Dec-2019 1.07 Inclusion of Beneficiary APIs for UPI

08-Mar-2020 1.09 Revision of FAQs

12-Mar-2020 1.10 Updating UPI request packet & introduction part

04-June-2020 1.11 Addition of Addendum – List of changes incorporated in v1.11

12-Dec-2021 1.14 New APIGEE IPs added in composite API

08-Sep-2021 1.16 IMPS recon API tranref number based search

4. Debits allowed for Nodal Account holding clients:

5. Daily transaction MIS:

(https://developer.icicibank.com). Client is required to register on the API developer portal and

Path: Home Page > Account > MIS Download

Several key benefits of incorporating composite API

Time & cost efficient

Secured medium of integration

Real-time output mechanism

Leads to increased productivity

To read more about composite API, click here

** For Loan disbursement, maximum limit is Rs. 2,00,000.

This value states the priority order for

same will be provided to the merchant

Mobile Number of the remitter. Mobile

channel-code For composite pay merchants, value of

profile-id Profile ID gets created during onboarding Yes

Random sequence number needs to be

payee-va Beneficiary VPA to be passed in this

payer-va Add the Sender’s VPA to be passed in

The column carries the total amount

This column is for the reference, which

MCC [Merchant Category Code] refers to

The CorpID of the corporate needs to be

SMS Corporate User ID

Update Request Number is a unique

This value column will consist of any of

Required to be passed only if a payment

payee-account This column will hold value in No

Initiation mode 00=Default, 01=QR

The purpose field is used especially for

This provides the preferred currency in

This value of the output refers to the status of the transaction –

Response [Number] Response code

This value refers to the transactions status message –

BankRRN [String] It is a unique 12-digit number used to refer to a particular transaction.

UpiTranlogId [String] Internal ID generated on the Switch.

SeqNo [Number] seq-no input parameter will be echoed back.

MobileAppData value will be always Json based “STRING" (JSON –

This is the response code populated by the Payer. For successful

This is the response code populated by the Payer. For successful

A Sample response packet for UPI transaction