Narada® SECURE-PG Interface NARADA(R) SECURE Payment Gateway API SPECIFICATIONS V4.0 Narada® SECURE-PG Interface 2 | Page COPYRIGHT NOTICE Copyright ©YALAMANCHILI International Pte Ltd. All rights reserved. These materials are confidential and proprietary to YALAMANCHILI International Pte Ltd. and no part of these materials should be reproduced, published in any form by any means, electronic or mechanical including photocopy or any information storage or retrieval system or should the materials be disclosed to third parties without the express written authorization of YALAMANCHILI International Pte Ltd. NON-DISCLOSURE AGREEMENT The reader of this document hereby undertakes to keep all information, documents, and knowledge of whatever kind obtained by them or by any of our advisers or agents (whether orally, in writing or in any way recorded or by observation (“the Information”), YALAMANCHILI International Pte Ltd. in connection with the proposals referred to in clause three below (hereafter referred to as “YALAMANCHILI”) secret and confidential and we further undertake, agree and acknowledge the following: The reader will not (save with the prior written consent of YALAMANCHILI or as required by law or the relevant regulatory body) communicate any of the Information to any other person or body, (“except associated companies”), in connection with the proposals referred to in the clause below. The reader will not make or permit or procure to be made or solicit or assist any other person to make any announcement or disclosure of our discussions with YALAMANCHILI, whether or not any discussions commence, proceed or are terminated, without YALAMANCHILI‘s prior written consent except as required by law or competent regulatory body. If agreements to any cooperation with YALAMANCHILI, at or after the date of such cooperation, no announcement of the cooperation will be made except by mutual agreement between YALAMANCHILI and the reader or as required by law or competent regulatory body. The reader will make no use of the Information for any purpose other than giving consideration to the possibility of putting forward proposals concerning a potential cooperation with YALAMANCHILI or for the purpose of such proposals, and, in particular, but without prejudice to the generality of the foregoing, the reader will not use the Information to obtain any commercial benefit or for any purpose detrimental to YALAMANCHILI. Narada® SECURE-PG Interface 3 | Page Table of Contents 1. INTRODUCTION ..................................................................................... 4 1.1 Overview ..................................................................................... 4 1.2 User and Transaction Flow ................................................................. 4 2. Narada ® SECURE Message ....................................................................... 7 2.1 Field Type .................................................................................... 7 2.2 Field Classification .......................................................................... 7 2.3 Special Character Handling ................................................................ 7 2.4 Request Message ............................................................................ 8 2.5 AR Message ................................................................................... 8 2.6 AS Message ................................................................................... 8 2.7 Request Message Format – AR ............................................................. 8 2.8 Sample Message – AR ........................................................................ 9 2.9 AC Message ................................................................................. 11 2.10 Response Message Format – AC .......................................................... 11 2.11 Sample Message – AC ..................................................................... 12 2.12 Response Codes ............................................................................ 13 3. Checksum Calculation........................................................................... 14 3.1 Request – Checksum Computation ...................................................... 14 3.2 Response – Checksum Computation ..................................................... 15 4. Security Implementation ....................................................................... 16 4.1 SSL Certificate ............................................................................. 16 4.2 Merchant Certificate ...................................................................... 16 4.3 Securing Private Keys & Certificates ................................................... 16 4.4 Certificate Validity ........................................................................ 17 4.4.1 Merchant Certificate ...................................................................... 17 4.4.2 NARADA® Secure Certificate ............................................................ 17 5. Sample Code ..................................................................................... 18 5.1 Sample Code in Java: To Sign Using PKI Keys ......................................... 18 5.2 Sample Code in Java: To Verify Using PKI Keys ....................................... 18 5.3 Sample Code in Java: To Sign/Verify Using HMAC .................................... 19 Narada® SECURE-PG Interface 1. INTRODUCTION 1.1 Overview This specification document provides detailed integration guidelines for Merchants to connect to the NARADA® SECURE for secure card-based payment processing. The NARADA® SECURE enables Merchants to initiate payment transactions, securely transmit card details, and receive real-time authorization responses while ensuring compliance with applicable security and regulatory standards. 1.2 User and Transaction Flow The following section describes the end-to-end user flow for transactions processed through the NARADA® SECURE, using browser redirection Step 1: Merchant Checkout Page Display The Merchant website displays the checkout page to the customer, presenting: • Transaction and billing details • Total payable amount • Card details capture The checkout page is hosted by the Merchant and is served over a secure HTTPS connection. Step 2: Checkout Submission & Browser Redirection When the customer clicks the Checkout / Pay button on the Merchant checkout page: • The payment form data is submitted using the HTML form action attribute. • The browser is redirected to the NARADA® SECURE URL, along with the required transaction parameters and cardholder details. This submission occurs as a browser POST redirection. Step 3: Request Reception at NARADA® SECURE NARADA® SECURE receives the payment request on the configured checkout URL through browser redirection. • The request includes: 4 | P a g e Narada® SECURE-PG Interface o Merchant identifiers o Transaction reference details o Cardholder data required for authentication and authorization Step 4: Merchant Validation– Upon receiving the request: • NARADA® SECURE performs merchant validation, including: Verification of merchant credentials Validation of transaction integrity Verification of request authenticity Only requests from authorized and active merchants are allowed to proceed further. Step 5: Request Forwarding to Directory Server (DS) After successful merchant validation: • NARADA® SECURE forwards the transaction and cardholder details to the Directory Server (DS) for authentication processing. • This step initiates the OTP-based authentication flow base Step 6: OTP Page Details from Directory Server The Directory Server processes the request and returns a response to NARADA® SECURE, which includes: • Authentication status • OTP challenge page details (URL and required parameters) Step 7: OTP Page Rendering Based on the response received from the Directory Server: • NARADA® SECURE loads the OTP authentication page within an iFrame. • The customer is prompted to complete OTP authentication. Step 8: OTP Submission & Issuer Validation The customer enters the OTP received on their registered mobile number. • The OTP submission request is sent to the Issuer system via the Directory Server. 5 | P a g e Narada® SECURE-PG Interface • The Issuer validates the OTP and performs authorization checks. Step 9: Final Response from Directory Server Upon completion of authentication and authorization. • The Directory Server sends the final transaction response (success or failure) to NARADA® SECURE. Step 10: Redirection Back to Merchant Page After receiving the final response: • NARADA® SECURE determines the transaction outcome. • The customer’s browser is redirected back to the Merchant website using the configured return URL. • The redirection includes the transaction reference and final transaction status. The Merchant website displays payment confirmation or failure message to the customer. Entity Responsibility Merchant Checkout Page Displays checkout UI, captures cardholder data, and submits payment request to NARADA® SECURE via browser POST NARADA® SECURE (Acquirer) Validates merchant, routes transaction and cardholder data to DS, and redirects final response to Merchant Directory Server (DS) Routes authentication requests and manages OTP challenge flow Issuer Performs OTP generation, authentication, and transaction authorization Merchant Page Display of final transaction status 6 | P a g e Narada® SECURE-PG Interface 2. Narada ® SECURE Message 2.1 Field Type Below are the types of fields supported by NARADA® SECURE Field Type Field Name Field Description N Numeric Number value in the range of 0-9 D Date time Date and time Timestamp (YYYYMMDDHH24MISS) in GMT C Character Alphanumeric value in the range of A-Z, a-z and 0-9 2.2 Field Classification Below are the field classifications in NARADA® SECURE: Field Type M Mandatory Description O Optional 2.3 Special Character Handling Below is the list of special characters supported by NARADA® SECURE: No Special Character Description 1. @ 2. / At-sign Slash 3. \ 4. ( Backslash Open bracket 5. ) 6. Close bracket Blank space 7. . 8. - Full stop Hyphen 9. _ 10. , Underscore Comma 11. & Ampersand 7 | P a g e Narada® SECURE-PG Interface 8 | Page 2.4 Request Message Merchants will send AR and AS messages to NARADA® SECURE. All messages are in Name / Value Pair (NVP) elements inside an HTML FORM. The name of the request fields must have a prefix “nar” as a message identifier. 2.5 AR Message AR message serves as a starting point for the Merchant to request authorization from the remitter bank. It contains the transaction information from the remitter, which is inclusive of Merchant ID, Merchant order number, Transaction amount and card details. 2.6 AS Message AS message serves as a query to obtain the current status of the transaction. This is important in the event that the Merchant does not receive any AC message from NARADA® SECURE. 2.7 Request Message Format – AR No Data Element Field Type Data Type Length Description 1 nar_msgType M C 2 Indicates message type. AR / AS 2 nar_merTxnTi me M D 14 Date and time of transaction originated from Merchant. YYYYMMDDHHMMSS 3 nar_orderNo M C 40 Unique order number generated by Merchant. 4 nar_merId M C 15 Merchant ID - provided by NARADA® Secure. E.g. 840000008400001 5 nar_merBankCode M N 2 Merchant account number registered in NARADA® Secure. 01 / 02 / 03 / 04 Default value = 01 6 nar_txnCurrency M C 3 Transaction currency. Default value = 242(FJD) 7 nar_txnAmoun t M N 16,2 Total amount. 8 nar_remitterEmail O EMAIL 50 Remitter‟ s email address. 9 nar_remitterMobile O N 10 Remitter‟ s mobile No Narada® SECURE-PG Interface 9 | Page 10 nar_cardType O VI/MC /UP 2 VI-Visa,MC-MasterCard ,JW – Jaywan, AX-AMEX, RP-Rupay 11 nar_cardNo M N 19 Card Number to be used for Payment 12 nar_expirydate M N 4 Expiry date in YYMM Format 13 nar_cvv M N 3 CVV2 of the Card 14 nar_nameoncard M C 26 Name on Card 15 nar_browserlanguage M C, SC 30 Browser Language 16 nar_browserscreenheig ht M C, SC 30 Browser Screen Height 17 nar_browserscreenwidt h M C, SC 30 Browser Screen Width 18 nar_browseruseragent M C, SC 30 Browser user Language 19 nar_checkSum M C - Checksum value. Hold message signature. 20 nar_paymentD esc M C, SC 30 Payment description. 21 nar_version M N 3 Version number. Default value = 1.0 22 nar_returnUrl M C 200 Return URL of Merchant to which IPG will send back the response 23 nar_Secure M C 9 This is a default value to know the type of algorithm is opted weather it is HMAC SHA 256(MERSECURE) or open SSL RSA public-private key(IPGSECURE) 2.8 Sample Message – AR
-- (MID+SID) -- RSA Encryption (Or) -- HMAC SHA-256
10 | P a g e Narada® SECURE-PG Interface 11 | Page 2.9 AC Message AC message is a response to AR and AS message. In response to AR/AS message, there will be AC messages sent by NARADA® Secure. This message format is similar to response to AR message but it will be sent in one string. Merchant is required to decode this message – refer to Sample Source Code for more details. AC message is the final acknowledgement message from NARADA® Secure. The message contains the transaction information from the bank, which is inclusive of the Transaction Amount, and payment Status. The message will be automatically submitted based on the response received from the DS. 2.10 Response Message Format – AC No Data Element Field Type Data Type Length Description 1 nar_msgType M C 2 Indicates message type. AC 2 nar_narTxnId M N 26 Payment Id of the transaction generated by NARADA® Secure for each payment request received from remitter. 3 nar_narTxnTime M D 14 Date and time NARADA® Secure processes transaction. YYYYMMDDHH24MISS 4 nar_merTxnTime M D 14 Date and time of transaction originated from Merchant. YYYYMMDDHH24mmSS 5 nar_orderNo M C 40 Order number generated by Merchant. 6 nar_merId M C 15 Merchant ID - provided by NARADA® Secure. E.g. 840000008400001 7 nar_txnCurrency M C 3 Transaction currency. Default value = 242(FJD) 8 nar_txnAmount M N 16,2 Total amount. 9 nar_checkSum M C - Checksum value. Hold message signature. 10 nar_remitterName O C, SC 40 Remitter‟ s name. 11 nar_remitterBankId O C 10 Provided by NARADA® Secure – ties to the bank where remitter has an account in. 12 nar_debitAuthCod e M C 2 Debit response code authorized by remitter Bank. Narada® SECURE-PG Interface 13 nar_debitAuthNo O C, SC 6 Mandatory if debit authorization code is „00‟ 14 nar_cardType M VI/MC/ VI- Visa, MC-Mater Card 15 nar_cardNo M C 19 Masked Card No 16 nar_remarks O C,SC 50 Transaction remarks if any 17 nar_paymentId O C 26 Payment Id of the transaction received for each approved payment request received from remitter. 2.11 Sample Message – AC Below is the sample of a full message for response to AC message:
12 | P a g e Narada® SECURE-PG Interface Below is the sample of NVP form element for response to AS message (in one line): nar_msgType=AC,nar_narTxnId=83720101111391200427111391,nar_narTxnTime=201410311 62137,nar_merTxnTime=20161031152438,nar_orderNo=4925065531352726881,nar_merId=M E00000585,nar_txnCurrency=242,nar_txnAmount=1.0,nar_checkSum=837CF44D341292342B 16CED69A836CD72A52EDCAC14E9AB8F8A97502AED9695E91B006E63E88C97258D1C37B04AE0 C2866DB911B648D6D2AEAAA96A188E64A9A3CACFEC0C8A948A9082D8EDC4A775F4B5FA17AF 102816EF930B017A9613BD52D42162D2F27D4CC6005DBF2A1A32F60B9AE905EB745100B4789B 8C4458792C6F0E07B53FA78707AA2D82C526B08FB971BCB4E711F5515E08E15C9D74AF5C8450 FFEAA97CF10BA61AB0D2B13B300CBCFE8F6AA9F9897D6EB48568938E2F67EC286AC0636FD7F DE7E53C82C9E33A80FBE2B7BD587A93606E7397536CE702332FBF4752E47B02256152CD830D7 28CE84A457239B3862AEA1DECE4115C990C633D648,nar_remitterName=Myclear&User,nar_r emitterBankId=TEST0001,nar_debitAuthCode=00,nar_debitAuthNo=999999&nar_cardType= EX&nar_cardNo=4233XXXXXXXX1232&nar_remarks=Approved&nar_paymentId=83720101111 391200427111391 Below is the sample of a full message response to AS/AR message and the value is URL encoded: nar_msgType=AC&nar_narTxnId=83720101111391200427111391&nar_narTxnTime=20141031 162137&nar_merTxnTime=20141031152438&nar_orderNo=4925065531352726881&nar_merI d=ME00000585&nar_txnCurrency=242&nar_txnAmount=1.0&nar_checkSum=837CF44D34129 2342B16CED69A836CD72A52EDCAC14E9AB8F8A97502AED9695E91B006E63E88C97258D1C37B 04AE0C2866DB911B648D6D2AEAAA96A188E64A9A3CACFEC0C8A948A9082D8EDC4A775F4B5F A17AF102816EF930B017A9613BD52D42162D2F27D4CC6005DBF2A1A32F60B9AE905EB745100B 4789B8C4458792C6F0E07B53FA78707AA2D82C526B08FB971BCB4E711F5515E08E15C9D74AF5 C8450FFEAA97CF10BA61AB0D2B13B300CBCFE8F6AA9F9897D6EB48568938E2F67EC286AC063 6FD7FDE7E53C82C9E33A80FBE2B7BD587A93606E7397536CE702332FBF4752E47B02256152CD 830D728CE84A457239B3862AEA1DECE4115C990C633D648&nar_remitterName=Test%20%26% 20User&nar_remitterBankId=TEST0001&nar_debitAuthCode=00&nar_debitAuthNo=999999& nar_cardType=EX&nar_cardNo=4233XXXXXXXX1232&nar_remarks=Approved&nar_paymentId =083720101111391200427111391 2.12 Response Codes Response codes are used in AC message to show the status. The code is based on the status returned by the respective bank to NARADA® Secure. Merchant should store the response code in their database for future transaction status verification and error debugging. Below are the response codes used by NARADA® Secure: Response Code Description 00 03 Approved Invalid Merchant 05 12 Do not honor Invalid Transaction 13 14 Invalid Amount Invalid Customer Credentials 20 30 Invalid Response Transaction Not Supported Or Format Error 45 Duplicate Merchant Order Number 13 | P a g e Narada® SECURE-PG Interface 47 48 Invalid Currency Transaction Limit Exceeded 51 53 Insufficient Funds No Savings Account 57 61 Transaction Not Permitted Withdrawal Limit Exceeded 65 76 Withdrawal Frequency Exceeded Transaction Not Found 78 80 Checksum Decryption Failed Buyer Cancel Transaction 84 85 Invalid Transaction Type Internal Error At Bank System UC UN Transaction Cancelled By Customer Unknown error TO NF Session Timeout at NARADA® Secure Entry Page Txn Not Found IM Invalid Message 91 N7 Issuer Declined or Transaction Timed out Invalid CVV2 3. Checksum Calculation 3.1 Request – Checksum Computation The message level security is implemented by using signing and verification of the message. Given below are the steps to sign a transaction request to NARADA® Secure: Step 1: Construct the source string a. The source string should be formed with all data element values b. The values should then be sorted by their data element name in the same order as mentioned below. c. Each element value should be separated by a “|” (pipe) character in between them. nar_msgType|nar_merTxnTime|nar_merBankCode|nar_orderNo|nar_merId|nar_txnCurre ncy|nar_txnAmount|nar_remitterEmail|nar_remitterMobile|nar_cardType|nar_cardNo|n ar_expirydate|nar_cvv|nar_nameoncard|nar_browserlanguage|nar_browserscreenheight |nar_browserscreenwidth|nar_browseruseragent|nar_checkSum|nar_paymentDesc|nar_ version|nar_mcccode|nar_returnUrl|nar_Secure Below is sample of source string, constructed from the sample message in AR|20200928231710|01|ORD_20200928231710|840000008400001|242|30.00|custo mermail@gmail.com|6798112040|VI|4561211234567890|3103|123|JohnDoe|en FJ|915|412|Mozilla/5.0 (Linux; Android 14; SM-A057F Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/133.0.6943.137 MobileSafari/537.36|2151CF6C22A3D0E035FEFAD70B52D77DB23F1ECDB4B45D8FB7 01F3DDE257664A3C232E09ABCF12E5D2D0C7A760AA63580DC9E68F61669DD10B53C3 C662711D7682F5FFC4A9E0C0A9BC9121CBC9913200BB2F46FC1247D66B01F2E1AA76 BE35CD5FB965AE7E998D334A0544FA1480FF18AA78C1D6ED2390CA3851AAB5DC75A3 14 | P a g e Narada® SECURE-PG Interface 6C6019588AF6F5948D446BAAD67FC904E3195D6B6F727A143C07A8995BF73DF1D9F97 7240B93BE6DF6AF5F74475EC7F9BCE54204A4AB47B2E30377F6F560BA0513925D84BC B00183FD6137E560B1732565A811B66690EEC2A461567239EB28A50AB8AC61255E0FA AF8454F578A0BDD5B49EDB757CAC69A14BC983DF67EAB118F07|eyJhbGciOiJIUzI1Ni J9.eyJpYXQiOjE3NjczNDgwMTMsImV4cCI6MTc2NzM0ODAxOCwianRpIjoiOGM3MWZh Y2QtNmNmNi00YjNmLTkzYWItNjVmMGQ2YWQ5MjUwIn0.XvQZ_wIbIvJglUlv7tT60mS 2MPE3CUSBePJChuoFjrk|TestPayment|1.0|4112|https://uat2.yalamanchili.in/pgsi m/checkresponse|IPGSECURE Step 2: Sign the source string a. Sign the constructed source string with Merchant‟ s private key/HMAC Key. b. Take the signed value and populate it into the “nar_checkSum” data element. 3.2 Response – Checksum Computation Step 1: Construct the source string a. The source string should be formed with all data element values received from DS. b. The values should then be sorted by their data element name c. Each element value should be separated by a “|” (pipe) charac.ter in between them. d. If there is any null value in the Response then keep it as blank value in below Source string which is separated with „|, do not use the null value while constructing below string. Below is format of source string, in ascending order: nar_cardNo|nar_cardType|nar_debitAuthCode|nar_debitAuthNo|nar_merId|nar_mer TxnTime|nar_msgType|nar_narTxnId|nar_narTxnTime|nar_orderNo|nar_remarks|na r_remitterBank Id|nar_remitterName|nar_txnAmount|nar_txnCurrency Below is sample of source string, constructed from the sample message 457817XXXXXX3227|EX|00|004502|840000008400001|20210203210840|AC|842701 01118049210203118049|20210203143843|ISP_5101527_20210203210840|Approved |01|Test&User|1.00|242 Step 2: Sign the source string a. Sign the constructed source string with Narada ® Secure’‟ s private key/HMAC Key. b. Take the signed value and populate it into the “nar_checkSum” data element. 15 | P a g e Narada® SECURE-PG Interface 4. Security Implementation This document follows RSA public-key cryptosystems to check the integrity of the message between Merchant and NARADA® Secure. 4.1 4.2 4.3 SSL Certificate Merchants should be responsible for their own SSL Certificate. Merchants may use a trial certificate in their UAT environment. However, for production environment, Merchant is required to procure their SSL certificate from a third-party Certificate Authority and other option to use self-signed certificate. Merchant Certificate Below are the steps required for Merchant to generate the private key and certificate The following flow is applicable for both first time certificate creation and certificate renewal: 1. Merchant should generate their own PKI key pair and ensure that the PKI private key is stored in a secure device. The PKI key pair can be generated using OpenSSL tool 2. OpenSSL is compatible for Windows, Linux and Unix-based OS and can be obtained from the following site: http://www.openssl.org. Information on the “certificate generating utility” can be viewed at http://www.openssl.org/docs/apps/req.html. Refer to Open SSL Command for Multiplatform for more details. 3. Following are the openssl commands for generating key pair and certificate a. Generate Key i. openssl genrsa -out _UAT_pvt.pem 2048 b. Generate CSR i. openssl req -new -key _UAT_pvt.pem -out .csr c. Self-Signed Certificate (Output Format is PEM) i. openssl x509 -in .csr -out _UAT_Certificate.pem -req -signkey _UAT_pvt.pem -days 730 d. The CSR (Certificate Signing Request) file (.csr) needs to be submitted to a CA (Certifying Authority) for obtaining public CA signed certificate. e. PEM to DER – To Convert to DER format i. openssl x509 -outform der -in _UAT_Certificate.pem -out _UAT_Certificate.der f. Please share the file _UAT_Certificate.der file with BSP. The PKI certificate is in .der format with 2048 bits key size while the signing algorithm is RSA. g. The signed value is in hexadecimal format. h. Merchant to procure their SSL certificate from third party Certificate Authority (CA) or use an self-signed certificate i. Certificate to be submitted to Narada@Secure Securing Private Keys & Certificates All key files and certificates should be secured using any of the following methods: 16 | P a g e Narada® SECURE-PG Interface 1. Cryptographic storage such as Java Key Store (sample tools: Key Man, Key Tool), or Windows cryptographic storage. This storage is password protected. 2. A secured folder outside Web application path. This folder should only be accessible to the system administrator and Merchant‟ s web application. 3. Any other method as guided by Merchant‟ s company security policy 4.4 Certificate Validity The validity for both merchants and NARADA® Secure certificates can be either 1 or 2 years. This duration applies to both Production and Testing environment. 4.4.1 Merchant Certificate Merchant can renew the Merchant certificate prior to the expiry date. Merchant is responsible for renewing the certificate, either by using their own program or manually replacing the certificate in a secured folder. 4.4.2 NARADA® Secure Certificate Email reminder will be sent to the merchants prior to the certificate expiry date. For Production certificate, reminder will be sent 1 month prior to the expiry date. For testing certificate, reminder will be sent one week prior to the expiry date. Merchant has to get the latest certificate from NARADA® Secure and replace the certificate accordingly. 17 | P a g e Narada® SECURE-PG Interface 18 | Page 5. Sample Code 5.1 Sample Code in Java: To Sign Using PKI Keys 5.2 Sample Code in Java: To Verify Using PKI Keys public String sign(PrivateKey prvkey,String data) throws Exception{ Signature sig = Signature.getInstance("SHA1WithRSA"); sig.initSign(prvkey); sig.update(data.getByte s()); byte[] signatureBytes = sig.sign(); return byteArrayToHexString(signatureBytes); } public static String byteArrayToHexString(byte b[]) { StringBuffer sb = new StringBuffer(b.length* 2); for (int i = 0; i < b.length; i++) { sb.append(hexChar[(b[i] &0xf0) >>> 4]); sb.append(hexChar[b[i] & 0x0f]); } return sb.toString(); } public boolean verify(PublicKey pubkey,String plaintext,byte[] signeddata) throws Exception{ Signature sig = Signature.getInstance("SHA1withRSA"); sig.initVerify(pubkey); sig.update(plaintext.getBytes()); logger.debug("Value Byte ["+signeddata.length+"]"); boolean status = sig.verify(signeddata); logger.debug("Verify Status: " +status); return status; } Narada® SECURE-PG Interface 19 | Page 5.3 Sample Code in Java: To Sign/Verify Using HMAC public static String signHashedRequest(String plainxml,String hKey) { String conhash=null; String hexstr =null; try { keyByte = hKey.getBytes("UTF-8"); byte[] messageBytes = plainxml.getBytes("UTF-8"); Mac mac = Mac.getInstance("HmacSHA256"); SecretKeySpec keySpec = new SecretKeySpec(keyByte, "HmacSHA256"); mac.init(keySpec); byte[] hashmessage = mac.doFinal(messageBytes); hexstr = Hex.encodeHexString(hashmessage).toLowerCase(); } catch (Exception e) { log.debug("Exception in Sign Hash="+e); } return hexstr; }