To perform a BRM-initiated payment transaction, PCM_OP_PYMT_COLLECT calls PCM_OP_PYMT_CHARGE.
The input flist contains a PIN_FLD_SESSION_OBJ field, which defines the session in which the event occurred: either a payment batch event or a refund batch event. The input flist also contains an array of specific operations to perform, so any number of operations can be batched together into a single call. The command is specified within each operation, so a single batch can contain a mixture of different commands. The billing information for each operation, such as credit card number and expiration date, can be specified as options on the input flist. If it isn't specified, PCM_OP_ PYMT_CHARGE retrieves the necessary information from the account storable objects specified within the operations. After it has all the data, the operations are forwarded to the opcode responsible for processing that payment method (for example, PCM_ OP_PYMT_CHARGE_CC and PCM_OP_PYMT_CHARGE_DD for credit card charges and direct debit charges, respectively).
Caution: If you use a credit card payment processor other than Paymentech, ensure that it uses duplicate transaction detection. If not, using the pin_recover utility can cause customers to be billed twice.
Note: The BRM-initiated payment collection utilities (pin_collect and pin_deposit) process payments for multiple bills associated with multiple /billinfo objects. To process externally initiated payments, such as checks and cash payments, for multiple /billinfo objects, write custom code that records the deposits you have received and calls PCM_OP_PYMT_COLLECT.
How BRM-Initiated Payment Transactions Are Performed
Each of the commands listed below in Table 2–1 can be executed as an operation. They are also called by Customer Center:
For each operation specified, the result of the operation is stored in the corresponding /event/billing/charge storable object.
The result is stored both as a numeric value returned by the payment processor, and as an enumerated result. The enumerated result should generally be used by applications to determine what happened because its values are independent of which settlement house was used.
Possible result values for an operation are shown in Table 2–2: Note:
■ For security reasons, the credit card CVV2 and CID numbers are
not stored in BRM. If the cc_collect entry is enabled, PCM_OP_ PYMT_CHARGE passes the security information to the payment processor for authorization and collection only at time of account creation. When collecting payments, PCM_OP_PYMT_CHARGE does not pass the information. In addition, it omits the PIN_FLD_ SECURITY_ID field from the input flist of PCM_OP_ACT_ USAGE so it is not written to the /event/billing/charge/cc object. The result is that the CVV2/CID information is stored in the database with a NULL value. For more information, see
"Requiring Additional Protection against Credit Card Fraud".
■ BRM supports direct debit transactions from checking accounts
only.
Table 2–1 Commands to Perform Transactions
Command Description
PIN_CHARGE_CMD_VERIFY Verify the address information. PIN_CHARGE_CMD_AUTH_ONLY Authorize a charge. The credit limit is
decreased on the credit card, but no charge is posted.
PIN_CHARGE_CMD_CONDITION Authorize and deposit a charge.
PIN_CHARGE_CMD_DEPOSIT Deposit a previously authorized charge. PIN_CHARGE_CMD_RECOVER_PAYMENT Recovers payments by using outstanding
checkpoints.
PIN_CHARGE_CMD_REFUND Refund a charge.
PIN_CHARGE_CMD_RESUBMIT Resubmit the batch of charges.
PIN_CHARGE_CMD_RFR For transactional payments, requests the RFR file to retrieve payments.
For nontransactional payments, reads the RFR file to retrieve payments.
Table 2–2 Result Values for Operation Input PIN_FLD_RESULT Output PIN_FLD_RESULT Output PIN_FLD_DESCR
How BRM-Initiated Payment Transactions Are Performed
General soft declines are failures that can be retried later with possible success. This includes reasons like insufficient credit limit and other transitory causes. General hard declines are failures that are unlikely to succeed if retried. These include reasons like lost and stolen credit card and chronic payment failures.
You can send multiple charges in one call by using the PIN_FLD_CHARGES array on the input flist. This array is designed for batch processing; you just make one call to PCM_OP_PYMT_CHARGE for a whole list of charges (or accounts to charge). These entries on the input flist of this opcode are of special interest:
■ The PIN_FLD_POID entry at the top of the input flist is only used for routing; it
only requires a correct (user) database number.
■ The PIN_FLD_ACCOUNT_OBJ entry is the POID of the account actually being
charged (verified) by this element of the PIN_FLD_CHARGES array. In a batch, this POID is presumably different for every element.
If the PCM_OPFLG_CALC_ONLY flag is set, the opcode does not change any fields in the database and does not create an /event/billing/charge object. However, it does provide a charge calculation to the caller by returning the fields that would have been used to create the event object and the charge item.
PIN_CHARGE_RES_SRVC_UNAVAIL PIN_RESULT_PASS Validation successful PIN_CHARGE_RES_FAIL_ADDR_AVS PIN_RESULT_FAIL Unable to verify address PIN_CHARGE_RES_FAIL_ADDR_LOC PIN_RESULT_PASS Street address mismatch PIN_CHARGE_RES_FAIL_ADDR_ZIP PIN_RESULT_FAIL ZIP code mismatch PIN_CHARGE_RES_FAIL_CARD_BAD PIN_RESULT_FAIL Credit card number not
valid
PIN_CHARGE_RES_FAIL_DECL_SOFT PIN_RESULT_FAIL General soft decline Card failed credit check PIN_CHARGE_RES_FAIL_DECL_HARD PIN_RESULT_FAIL General hard decline
Card failed credit check PIN_CHARGE_RES_FAIL_NO_ANS PIN_RESULT_FAIL No answer from
settlement house Unable to validate now PIN_CHARGE_RES_CHECKPOINT PIN_RESULT_FAIL Unable to validate now PIN_CHARGE_RES_CVV_BAD PIN_RESULT_FAIL Security ID check failed
Note: By default, account balances are not updated if there is a decline. To update account balances when a decline occurs, you must customize the PCM_OP_PYMT_POL_CHARGE policy opcode.
Table 2–2 (Cont.) Result Values for Operation Input PIN_FLD_RESULT Output PIN_FLD_RESULT Output PIN_FLD_DESCR
How BRM-Initiated Payment Transactions Are Performed
PCM_OP_PYMT_CHARGE works as follows:
1. Opens a transaction.
2. Using checkpoints, creates the /event/billing/charge event for each payment.
3. Calls PCM_OP_PYMT_CHARGE_CC or PCM_OP_PYMT_CHARGE_DD,
depending on the payment method, to process the charges from the payment DM.
4. Updates the checkpoint in the charge event for each transaction received from the payment DM.
5. For each PIN_FLD_CHARGES in the input flist:
a. Closes billing for the account.
b. Creates a payment item and records the account number, bill number, and transaction ID from the input flist, and the fact that the money has been received.
c. Adds the PIN_FLD_STATUS value in the output flist.
For failed payments, sets the PIN_FLD_STATUS value to PIN_PYMT_ FAILED. For successful payments, sets the PIN_FLD_STATUS value to PIN_ PYMT_SUCCESS.
d. Calls the PCM_OP_PYMT_POL_CHARGE policy opcode to update the reasons array.
e. Sends the payment status and the reasons array (PIN_FLD_REASON_ID and PIN_FLD_REASON_DOMAIN_ID) to PCM_OP_PYMT_COLLECT.
f. For payments with a successful status, applies the charge to the customer’s account. For payments with a failed status, sends the PIN_FLD_STATUS value to the PCM_OP_PYMT_APPLY_FEE to create the payment fees.
6. Closes the transaction.
How BRM Performs Credit Card Charges
To perform a credit card charge, PCM_OP_PYMT_CHARGE calls PCM_OP_PYMT_ CHARGE_CC.
The PCM_OP_PYMT_CHARGE_CC input flist contains the PIN_FLD_SESSION_OBJ field, which references either the /event/billing/batch/payment or
/event/billing/batch/refund object. This determines the batch type being submitted (payment or refund).
The PCM_OP_PYMT_CHARGE_CC input flist contains an array of specific operations to perform, so any number of operations can be batched together into a single call. The command is specified within each operation, so a single batch can contain a mixture of different commands. This opcode supports all commands handled by PCM_OP_ PYMT_CHARGE.
The operations are forwarded to the credit card processing Data Manager (for example, the Paymentech DM) for processing.
Caution: Do not set the PCM_OPFLG_CALC_ONLY flag if you are connected to a payment processor, for example Paymentech. This may cause the charge to be sent to the credit card company, even though the charge is not created in BRM. This may result in a double charge on the account.
How BRM-Initiated Payment Transactions Are Performed
With most credit card payment services, performing an authorization is much faster than a conditional deposit (authorization plus deposit). Thus, for applications where latency is important, it may be desirable to perform just the authorization step in real-time. BRM daily billing performs the necessary deposits for all outstanding authorizations from the previous day. This removes a significant amount of latency from the real-time process, but still authorizes the charge so it is guaranteed to deposit successfully.
The set of Paymentech return codes handled by BRM is listed in the BRM_
Home/sys/dm_fusa/fusa_codes file. As explained in "Changing How BRM Handles Paymentech Authorization Return Codes", these codes can be modified. See "How BRM-Initiated Payment Transactions Are Performed" for a list of the PIN result codes from BRM-initiated payment transactions.
Unless the PCM_OPFLG_CALC_ONLY flag is specified, PCM_OP_PYMT_CHARGE_ CC creates an /event/billing/charge/cc storable object for each operation. If an array of operations was specified, then more than one event storable object is created. The event storable objects are created even if the credit card operations cannot be performed.