BRM Chase

Disclaimer This document and the subsequent documents give a very high level overview of BRM system and customization of one aspect of the system. In order to get a deeper understanding of the all the concepts at a greater depth, it is recommended to refer to the BRM implementation guide which is provided with any version of the BRM product. The following material has been written taking BRM Documentation as a basis to reflect some custom changes made to Paymenetch engine.
BRM – Chase Paymentech Integration (Static Integration with Static values)This document deals with a static integration of Chase Paymentech with the Custom  Paymentech DM of a BRM System. The following diagram gives an idea of the flow.
Actual Scenario: When a transaction with respect to Paymentch happens from the Customer Center of BRM, it has to talk to payment processor, which is Chase Paymentech for the current version. Required fields like name, credit card number, address, payment amount are obtained from BRM database and the type transaction like authentication, authorization, payment are specified by the Customer Center. A URI string is generated concatenating the above values in a format Chase Paymentech understands. Hostname/IP Address and port number are attached to the above URI to give a complete URL which is passed on to the payment processor Data Manager. This DM speaks to the payment processor. The payment processor processes the fields in the URL and gives out a response. The response is captured and sent back to the Paymentech DM which in turn passes it on to the Customer Center. The above operation is similar to a Java HTTP Request and Response but the implementation is done in Linux and C.  Assumptions and details are as given below.Assumptions:

1. For the current static implementation, no data is fetched from BRM Database. Static data is used in the code.
2. This demo tests CC Authorization only.
3. Response of the URL is captured  but not sent back to the DM/Customer Center.

Procedure: For the C code the steps are:

1. Get the requirements of the URL from Chase Paymentech. This includes various required fields.
2. In a C program define all the required fields in a Structure.
3. Assign the members of the structure, the corresponding values and concatenate them to a string. In the actual implementation values are dynamically assigned through flist operations.
4. Assign the IP address, port number values and concatenate it to the above string to generate a URL.
5. Write this URL to file.

For the shell script (call.sh) which actually calls the URL, the steps are:

1. Write entries to compile and run the C file.
2. Copy the generated file to a variable.
3. An operation similar to HTTP Request/Response in Linux via command line is done by invoking a utility called  ‘curl’. Please refer man pages for the same . In the current case options –dump-header <filename> is used to get the header information of the response generated. The header information contains the status code of the transaction. The status code is reflected in the ‘OapfStatus’ Field of the header. 0000 designates Success , 0005 or any other code designates a failure.

Paymentech:If Paymentech Manager is installed, Paymentech gets integrated with the BRM system for credit card and debit card processing. dm_fusa  is the name of the process by which Paymentech is run on Linux/Uinix system. In order to setup a connection to a payment processor following information about it is needed

• 1. Go to /opt/portal/7.4/sys/data/pricing/example and open pin_ach file. Enter the following entry at the end of the file, just below the ‘fusa’ entry.       chase          0.0.0.20 /payment 1000  ibizsoft    1
     • chase is the name of the payment processor
     • 0.0.0.20 /payment 1000  is the Portal Object ID of the DM which identifies the payment processor. 0.0.0.20 is the database number and /payment  is the storable object where the POID resides. 1000 is the object.
     • ibizsoft is the merchant name and 1  is the merchant channel-id. Every merchant should be configured separately with a different channel number. The configuration should be done in payment_channel.en_US for US based merchants at /opt/portal/7.4/sys/msgs/paymentchannel . Note the examples in the file and key in the new entry accordingly. Also note that a basic pin.conf file should be present in this directory.
  2. Save the pin_ach file.
  3. Load the file into /config/ach by using load_pin_ach utility.
  1. Compile the custom code (let it be called dm_generic.c ) using the system given makefile at   /opt/portal/7.4/ PortalDevKit/ source/templates/dm_template.
  2. Create a directory in /opt/portal/7.4/sys and copy the .so file that had got generated after compilation.
  3. Copy the dm_oracle start and stop scripts and rename the scripts to start_dm_generic and  stop_dm_generic.
  4. Create a symbolic link between dm and dm_generic.
  5. Edit the start_dm_generic to reflect dm_generic environment names, process ids, paths and log file names.
  6. Edit the stop_dm_generic to reflect dm_generic log files, directories , process ids and modify to tke kill  – QUIT to incorporate the dm_generic process id.
  7. Copy the pin.conf file from dm_oracle to $PIN_HOME/sys/dm_generic directory and change the entries to point to the Chase Paymentech.
     • dm       dm_port          14950
     • dm       dm_name        -
     • dm       dm_db_no       0.0.0.20/0
     • dm       dm_log_file     /opt/portal/7.4/sys/dm_generic/dm_generic.pinlog
     • dm       dm_sm_obj     /opt/portal/7.4/sys/dm_generic/dm_generic ${LIBRARYEXTENSION}
  8. Start the custom DM and check at unix prompt by ps –aef|grep dm_generic.
  • IP address/hostname and port number
  • Merchant numbers supported for each currency.
  • dm_if_init_process ( )  This function spawns a child DM process whenever a new request is passed and reads the custom DM configuration file.
  • dm_if_process_op ( ) CM request processing function
  • dm_if_terminate_connect ( ) Cleans  up the CM Connection when the CM or DM get disconnected
  • dm_if_terminate_process ( ) Called when the custom DM is stopped by the stop script .
  • Open the pin.conf file of the CM and add an enrty for this custom DM mentioning the database number, the machine on which this DM runs or the IP addresses, and the port number
  • Add an enrty to the custom FM written, if any. The format would be
  • 1. Configure the Storage Manager utility to retrieve/ send data to BRM Database.
    2. Develop custom code for FM policy opcodes to trap input requests and direct them to the proper dm.
    3. Develop search flists to find the correct DM.
    4. Enhance the configuration of Custom Paymentech Data Manager pin.conf  file to reflect the payment processor information, the database information , merchant id and channel id.
    5. Configure the CM/CMMP correspondingly to reflect updations of DM and payment processor  in the CM/CMMP pin.conf file.
    6. Update fusa_codes file at /opt/portal/7.4/sys/dm_fusa/test for the custom DM that is required to handle requests/responses from payment processor.
    7. Interpret responses from the payment processor and let the Customer Center know about it.
    8. Test various types of transactions like  payment, authorization, verification.
    9. Test for concurrent transactions.
    10. Test for other payment processors.
    • Restart the CM

  Source Codes with enhancements in comments:The following code implements static values to generate a URL. In order to generate dynamic URLs, proper opcodes have to be used along with the ideas presented in comments in the declaration of  structure ‘uri’

//fetchdata.c


//fetchdata.c

#include<stdio.h>

#include<string.h>

#include<ctype.h>

//#include<system.h>

//#include<unistd.h>

#include<malloc.h>

struct uri
{
char str_OapfAction[50]; // <<<— dont know how //to get this code/value
char str_OapfNlsLang[50]; // <<<— as of now //leave it blank
char str_OapfPmtInstrID[50]; // <<<— cc number. //select PIN_FLD_CC_INFO.PIN_FLD_DEBIT_NUM = ’5421690122208331′ where PIN_FLD_POID = $DB /payinfo/cc 26808
char str_OapfPmtInstrExp[50]; // <<<— expiry date. //select PIN_FLD_CC_INFO.PIN_FLD_DEBIT_EXP = ’09/12′ where //PIN_FLD_POID =
//$DB /payinfo/cc 26808
char str_OapfTrxnRef[50]; // <<<— as of now //leave it blank
char str_OapfPmtInstrDBID[50];// <<<— as of now fix //it to 99
char str_OapfPostalCode[50]; // <<<— zip code . //select PIN_FLD_CC_INFO.PIN_FLD_ZIP = ’75034′ where //PIN_FLD_POID = $DB /payinfo/cc 26808
char str_OapfCnty[50]; // <<<— as of now //leave it blank
char str_OapfCustName[50]; // <<<— holder name. //select PIN_FLD_CC_INFO.PIN_FLD_NAME = ‘Kavan Shah’ where //PIN_FLD_POID = $DB /payinfo/cc 26808
char str_OapfAuthType[50]; // <<<— dont know how //to get this code/value
char str_OapfCity[50]; // <<<— city . select //PIN_FLD_CC_INFO.PIN_FLD_CITY = ‘Frisco’ where //PIN_FLD_POID = $DB /payinfo/cc 26808
char str_OapfStoreId[50]; // <<<— dont know how //to get store ID
char str_OapfState[50]; // <<<— state. select //PIN_FLD_CC_INFO.PIN_FLD_STATE = ‘TX’ where PIN_FLD_POID = //$DB /payinfo/cc 26808
char str_OapfPrice[50]; // <<<— should get it //from /invoice or /balance, need to figure it out.
char str_OapfOrderId[50]; // <<<— dont know how //to get order ID
char str_OapfCntry[50]; // <<<— country. //select PIN_FLD_CC_INFO.PIN_FLD_COUNTRY = ‘TX’ where //PIN_FLD_POID = $DB /payinfo/cc 26808
char str_OapfCurr[50]; // <<<— should get //currency value from my system , should be in /plan
char str_OapfRetry[50]; // <<<— as of now, fix //’no’
char str_OapfCVV2[50]; // <<<— my system //doesnt store CVV field, should I create it ..??
char str_OapfAddr3[50]; // <<<— address comes //in only one field in my system. I dont know how to break //this up
char str_OapfAddr2[50]; // <<<— select //PIN_FLD_CC_INFO.PIN_FLD_ADDRESS = ’9300 Wade Blvd’ where //PIN_FLD_POID = $DB /payinfo/cc 26808
char str_OapfAddr1[50];
};

int main()
{
struct uri URI;
FILE *fp;

char str_protocol[50] = “http://”;
char str_hostip[50] = “192.168.15.20″;
char str_port[50] = “:8100″;
char str_proctype[50] = “/servlets/oramipp_pmt?”;
//char *URL;
char *temp;

strcpy(URI.str_OapfAction,”OapfAction=oraauth&”);
strcpy(URI.str_OapfNlsLang,”OapfNlsLang=&”);
strcpy(URI.str_OapfPmtInstrID,”OapfPmtInstrID=5421690122208331&”);
strcpy(URI.str_OapfPmtInstrExp,”OapfPmtInstrExp=09/12&”);
strcpy(URI.str_OapfTrxnRef,”OapfTrxnRef=&”);
strcpy(URI.str_OapfPmtInstrDBID,”OapfPmtInstrDBID=99&”);
strcpy(URI.str_OapfPostalCode,”OapfPostalCode=75034&”);
strcpy(URI.str_OapfCnty,”OapfCnty=&”);
strcpy(URI.str_OapfCustName,”OapfCustName=Kavan+Shah&”);
strcpy(URI.str_OapfAuthType,”OapfAuthType=AUTHONLY&”);
strcpy(URI.str_OapfCity,”OapfCity=Frisco&”);
strcpy(URI.str_OapfStoreId,”OapfStoreId=041756:000001&”);
strcpy(URI.str_OapfState,”OapfState=TX&”);
strcpy(URI.str_OapfPrice,”OapfPrice=1.00&”);
strcpy(URI.str_OapfOrderId,”OapfOrderId=3536&”);
strcpy(URI.str_OapfCntry,”OapfCntry=US&”);
strcpy(URI.str_OapfCurr,”OapfCurr=USD&”);
strcpy(URI.str_OapfRetry,”OapfRetry=no&”);
strcpy(URI.str_OapfCVV2,”OapfCVV2=234&”);
strcpy(URI.str_OapfAddr3,”OapfAddr3=&”);
strcpy(URI.str_OapfAddr2,”OapfAddr2=Suite&”);
strcpy(URI.str_OapfAddr1,”OapfAddr1=Wade+Blvd”);

temp = (char *) malloc(strlen(URI.str_OapfAction)+1);
strcpy(temp,URI.str_OapfAction);
//URL = (char*)
//strcat(temp,URI.str_OapfNlsLang);
//strcat(URL);
strcat(str_protocol,str_hostip);
strcat(str_protocol,str_port);
strcat(str_protocol,str_proctype);
strcat(str_protocol,URI.str_OapfAction);
strcat(str_protocol,URI.str_OapfNlsLang);
strcat(str_protocol,URI.str_OapfPmtInstrID);
strcat(str_protocol,URI.str_OapfPmtInstrExp);
strcat(str_protocol,URI.str_OapfTrxnRef);
strcat(str_protocol,URI.str_OapfPmtInstrDBID);
strcat(str_protocol,URI.str_OapfPostalCode);
strcat(str_protocol,URI.str_OapfCnty);
strcat(str_protocol,URI.str_OapfCustName);
strcat(str_protocol,URI.str_OapfAuthType);
strcat(str_protocol,URI.str_OapfCity);
strcat(str_protocol,URI.str_OapfStoreId);
strcat(str_protocol,URI.str_OapfState);
strcat(str_protocol,URI.str_OapfPrice);
strcat(str_protocol,URI.str_OapfOrderId);
strcat(str_protocol,URI.str_OapfCntry);
strcat(str_protocol,URI.str_OapfCurr);
strcat(str_protocol,URI.str_OapfRetry);
strcat(str_protocol,URI.str_OapfCVV2);
strcat(str_protocol,URI.str_OapfAddr3);
strcat(str_protocol,URI.str_OapfAddr2);
strcat(str_protocol,URI.str_OapfAddr1);
//printf(“%s\n”,str_protocol);
fp = fopen(“URL1.txt”, “w”);
if ( fp == NULL)
{
puts(“Cannot Open URL.txt”);
//fclose(fp);
//exit(0);

}
fprintf(fp,”%s\n”,str_protocol);
fclose(fp);
return 0;
}

The following unix code compiles the above C code and calls the Chase Paymentech.

#!/bin/bash
# This is call.sh file
#
#filename = header_$(date +%Y%m%d)
# call Curl

CHECK=” ”
SUCCESS=”0000″
FAILURE=”0005″
gcc fetchdata.c -o fetchdata
./fetchdata

URL=`cat URL1.txt`
echo $URL
curl $URL –dump-header header.txt
CHECK=`grep OapfStatus header.txt | cut -f2 -d:`
echo “OapfStatus:”$CHECK

The Chase Paymentech result is reflected in OapfStatus field. This value has to be passed on to Customer Center. The OapfStatus field values have to be written in fusa_codes file. The resultant output for the above script file is shown below.

http://192.168.15.20:8100/servlets/oramipp_pmt?OapfAction=oraauth&OapfNlsLang=&OapfPmtInstrID=5446364689884261&OapfPmtInstrExp=09/12

&OapfTrxnRef=&OapfPmtInstrDBID=99&OapfPostalCode=75034&OapfCnty=&OapfCustName=Kavan+Shah&OapfAuthType=AUTHONLY

&OapfCity=Frisco&OapfStoreId=041756:000001&OapfState=TX&OapfPrice=1.00&OapfOrderId=3536&OapfCntry=US&OapfCurr=USD

&OapfRetry=no&OapfCVV2=234&OapfAddr3=&OapfAddr2=Suite&OapfAddr1=Wade+Blvd
Inside processTokenization
Creating New Order Type.
Process level two and three
total line :0
Creating tokenization request object
Creating marshaller

Creating file : chase_tokenization_12812.xml
Creating XML File
File Generated.
Sending authorization request
Response Received
Response :
<?xml version=”1.0″ encoding=”UTF-8″?>
<Response>
<NewOrderResp>
<IndustryType></IndustryType>
<MessageType>A</MessageType>
<MerchantID>041756</MerchantID>
<TerminalID>001</TerminalID>
<CardBrand>MC</CardBrand>
<AccountNum>5424000000000015</AccountNum>
<OrderID>3536</OrderID>
<TxRefNum>4C5303C01BA5B507A66FB9C521AD9AC7ED975478</TxRefNum>
<TxRefIdx>0</TxRefIdx>
<ProcStatus>0</ProcStatus>
<ApprovalStatus>1</ApprovalStatus>
<RespCode>00</RespCode>
<AVSRespCode>B </AVSRespCode>
<CVV2RespCode>M</CVV2RespCode>
<AuthCode>tst079</AuthCode>
<RecurringAdviceCd></RecurringAdviceCd>
<CAVVRespCode></CAVVRespCode>
<StatusMsg>Approved</StatusMsg>
<RespMsg></RespMsg>
<HostRespCode>100</HostRespCode>
<HostAVSRespCode>I3</HostAVSRespCode>
<HostCVV2RespCode>M</HostCVV2RespCode>
<CustomerRefNum></CustomerRefNum>
<CustomerName></CustomerName>
<ProfileProcStatus>0</ProfileProcStatus>
<CustomerProfileMessage>Use Profile Transaction Completed</CustomerProfileMessage>
<RespTime>125424</RespTime></NewOrderResp></Response>
Unmarshalling Response
Authorization Response Reference : com.ibiz.chase.payment.web.impl.ResponseImpl@10a2ca6
Authorization Finished
OapfStatus: 0005

• Further Enhancements Needed:  This document specifies a rudimentary description of the integration between a BRM system and a Payment Processor. In order to make end-to-end integration, following issues/requirements have to met.

  1.Configure the Storage Manager utility to retrieve/ send data to BRM Database.
  2.Develop custom code for FM policy opcodes to trap input requests and direct them to the proper dm.
  3.Develop search flists to find the correct DM.
  4.Enhance the configuration of Custom Paymentech Data Manager pin.conf  file to reflect the payment processor information, the database information , merchant id and channel id.
  5.Configure the CM/CMMP correspondingly to reflect updations of DM and payment processor  in the CM/CMMP pin.conf file.
  6.Update fusa_codes file at /opt/portal/7.4/sys/dm_fusa/test for the custom DM that is required to handle requests/responses from payment processor.
  7.Interpret responses from the payment processor and let the Customer Center know about it.
  8.Test various types of transactions like  payment, authorization, verification.
  9.Test for concurrent transactions.
  10.Test for other payment processors.

  The above list may not be comprehensive enough to perform end-to end integration.  Coding/configuration has to be done to resolve/meet each one of the above issues/requirements separately. One can look at the dm_fusa Paymentech module including the start/stop scripts, pin.conf files and log files to mimic the required process.