This chapter describes the Oracle Communications Billing and Revenue Management (BRM) Single Euro Payments Area (SEPA) payment processing.
For more information on payments, see "About Payments".
SEPA payments are electronic payment transfers between bank accounts in the euro countries that participate in SEPA.
SEPA defines a common set of standards and rules for any organization or individual making or receiving payments in euro. With SEPA, all bank accounts are uniquely identified by the International Bank Account Number (IBAN), and the banks related to the accounts are uniquely identified by the Business Identifier Code (BIC). These standards improve the ability of consumers to transfer money, for example, from the home bank account to an account in another country that participates in SEPA.
Note:
BRM supports the SEPA specifications in the SEPA Rulebook Version 7.0.SEPA defines two payment schemes: SEPA Direct Debit and SEPA Credit Transfer. Both SEPA Direct Debit and SEPA Credit Transfer are supported as BRM-initiated payments.
SEPA Direct Debit is a payment transfer that is initiated by the service provider for automated payments from the customer's bank account.
This type of payment is commonly used for recurring payments such as automated payments for a monthly subscription charge (can also be used for one-time payments) and requires a pre-authorization (mandate) from the customer.
SEPA Credit Transfer is a payment transfer that is initiated by the service provider to transfer money from the service provider's bank account to the customer's bank account.
SEPA Credit Transfer is used to give refunds to customers. The service provider must provide the customer's IBAN and the customer's bank's BIC to initiate the credit transfer.
Use Customer Center to register your customer's SEPA payment information.
When you register a new customer (or when an existing customer purchases a new service) and the customer wants to pay by SEPA Direct Debit, specify SEPA as the payment method.
In addition to the customer's name and address information, your customer must provide a mandate, a pre-authorization form that is signed by your customer, to debit the customer's bank account automatically through SEPA Direct Debit.
For more information about creating accounts using the SEPA payment method, see the discussion about creating customer accounts in the Customer Center Help.
SEPA Direct Debit and SEPA Credit Transfer payments are allowed in euro only.
When you register a customer, the account's primary currency must be euro.
To pay for services by SEPA Direct Debit, your customer must first fill out and sign a mandate (provided by the service provider) to authorize automatic payments from the customer's bank account.
SEPA requires the service provider to send this mandate information with each collection of the SEPA Direct Debit payment. The service provider is also required to retain the mandate (throughout the period when the customer is using SEPA Direct Debit and according to the national legal requirements and its Terms and Conditions) along with any amendments or information concerning its cancellation or lapse with the service provider's bank.
The mandate must include the following information:
Your customer's name and address
Your customer's IBAN
Your customer's bank's BIC
Your business name and address
Your creditor identification number
Type of mandate (recurrent or one-off)
Your customer's signature
Your customer service representative (CSR) receives the signed mandate and enters the data into the BRM system using Customer Center.
A mandate is identified by the unique mandate reference (UMR) number. If a unique mandate reference number is not provided, BRM automatically generates one for the mandate.
In BRM, a mandate is associated with a bill unit and is valid for collection of the payment for this bill unit. If your customer has multiple services associated with different bill units and wants to pay for the different services by SEPA Direct Debit, your customer must provide separate mandates for the collection of payments for each service. If the same mandate is associated with multiple services, it is assumed that your customer has authorized collection of payment for all the services using a single mandate.
For information on the requirements for retaining the paper mandate and any amendments to it, refer to the SEPA Direct Debit Rulebook.
Mandates are of two types: recurrent and one-off.
A recurrent mandate is used to collect multiple bill payments for a bill unit; for example, to collect a recurring monthly service fee. If a recurrent mandate is not used within a 36-month period, it is considered expired; BRM automatically sets the mandate status to Expired.
A one-off mandate is used to collect only one bill payment for a bill unit. For example, your customer pays bills regularly by check or credit card but wants to pay a bill by SEPA Direct Debit. After collection of the one bill payment, the mandate cannot be used to collect other bill payments; BRM automatically sets the mandate status to Expired.
You cannot re-activate a mandate that is expired. A new mandate is required to process any SEPA payment requests.
Use Customer Center to change or delete your customer's SEPA payment information.
You can do the following:
Change payment method (see "Changing the SEPA Payment Method")
Delete the payment method (see "Deleting the SEPA Payment Method")
Change the mandate information (see "Changing the Mandate Information")
See Customer Center Help for more information.
If your customer wants to change from SEPA to a different payment method, you need to register new payment information and associate the customer's services with the new payment information. Your customer's existing SEPA payment method in the BRM database is not changed.
If your customer wants to change from a different payment method to SEPA, you need to first register the SEPA payment information. For instance, if your customer is currently paying by credit card and wants to pay by SEPA Direct Debit instead, register new payment information that includes the SEPA-related information such as the IBAN, BIC, and the mandate information. Your customer's existing payment information in the BRM database is not changed.
When you delete a SEPA payment method, BRM also cancels the mandate that is associated with the payment method and the mandate cannot be used with any future payment requests; a new mandate is required.
You cannot delete the SEPA payment method if it is associated with a bill unit.
If the SEPA payment method is associated with a payment request that is pending, BRM cancels the mandate only for future payment requests.
To update the customer information in a mandate, you use Customer Center.
To update the creditor information in a mandate, you update the creditor configuration object. See "Updating the Creditor Information" for more information.
BRM stores the new mandate information and also keeps a record of the information that is amended and sends both the new and amended information to the bank with the next SEPA payment collection.
Your creditor information includes your business name and address and the creditor identification number. You load the creditor information into the creditor configuration objects (/config/creditor) in the BRM database. For more information, see "Setting Up and Loading Creditor Information".
During customer registration, Customer Center retrieves your creditor configuration information from the BRM database.
Creditor information is stored in the /config/creditor object in the BRM database.
To set up and load creditor information:
Open the BRM_Home/sys/data/config/config_creditor.xml file in a text editor, where BRM_Home is the directory in which BRM is installed.
In the CREDITOR_INFO child element, provide the values listed in Table 3-1.
Table 3-1 Elements in the CREDITOR_INFO Child Element
| Element | Description |
|---|---|
|
ADDRESS |
Your business street address |
|
BIC |
Your Business Identifier Code |
|
BRAND_OBJ |
The brand account for your business |
|
CITY |
The city where your business is located |
|
COUNTRY |
The country where your business is located |
|
CREDITOR_ID |
Your creditor identification number |
|
CURRENCY |
Your currency |
|
IBAN |
Your International Bank Account Number |
|
NAME |
Your business name |
|
REF_PARTY |
The name of your reference party |
|
REF_PARTY_ID_CODE |
The identification code of your reference party |
|
ZIP |
The postal code where your business is located |
Save and close the file.
Run the following command, which loads the contents of the file into the /config/creditor object:
BRM_Home/apps/load_config/load_config -v config_creditor.xml
The load_config utility validates the contents using the config_creditor.xsd file before loading the data.
See "load_config" in BRM Developer's Guide for more information about the utility's syntax and parameters.
Read the object by using the robj command with the testnap utility or by using Object Browser to verify that the creditor configurations are loaded.
See "Using testnap" in BRM Developer's Guide for general instructions on using the testnap utility.
See "Reading Objects by Using Object Browser" in BRM Developer's Guide for information on how to use Object Browser.
Stop and restart the Connection Manager (CM). For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
You can use load_config utility to add new creditor configuration data; it does not overwrite any existing data in the configuration objects. However, to update or delete a creditor configuration object, you need to use opcodes. For more information, see "Updating the Creditor Information".
To update the creditor information, use the PCM_OP_CUST_AMEND_CREDITOR_INFO opcode. This opcode updates the creditor name and the creditor ID only.
PCM_OP_CUST_AMEND_CREDITOR_INFO uses the creditor ID to update the /config/creditor object with the new creditor information.
Any update to a creditor configuration triggers automatic updates to all the mandates with this creditor ID in the BRM database. For example, if you have multiple customers that have mandates with the same creditor ID, BRM automatically locates the customers' payment information and updates their mandates with the new creditor information.
Processing of SEPA payments includes these tasks:
Creating the payment requests in BRM. See "Creating SEPA Direct Debit Payment Requests" and "Creating SEPA Credit Transfer Payment Requests".
Generating the SEPA request files. See "Generating SEPA Request XML Files".
Collecting the payments. See "Sending the SEPA Request XML Files to Your Bank to Collect Payment".
Handling the failed payments. See "Processing SEPA Response XML Files to Handle Failed Payment Transactions".
You run the pin_collect utility to create the SEPA Direct Debit payment requests in the BRM database. The pin_collect utility is run as part of the pin_bill_day script.
The SEPA Direct Debit payment requests record the customer's payment details, such as the amount due and mandate information, and the payment transaction ID.The pin_collect utility retrieves the pending bills for accounts that use the SEPA payment method and calculates the amount due. For each bill unit, it records the payment details in the payment request (/sepa/dd) and sets the payment request status to Pending.
The pin_collect utility does not create a payment request if the mandate for the bill unit is expired. To collect the payment, your customer has to provide a valid mandate or use another payment method.
SEPA Direct Debit payments are applied to the accounts at the time payment requests are created (before payment requests are sent to the bank). The pin_collect utility calls the PCM_OP_PYMT_COLLECT opcode to apply the payments and update the account's balance in the BRM database. If your bank is unable to collect the payment from your customer's bank, you reverse the payment recorded in BRM using the pin_sepa utility. For more information, see "Processing SEPA Response XML Files to Handle Failed Payment Transactions".
For more information about the pin_collect utility, see "pin_collect".
You run the pin_mass_refund and the pin_refund utilities to create SEPA Credit Transfer refund requests in the BRM database.
The SEPA Credit Transfer payment requests record the customer's payment details, such as the refund amount and the payment transaction ID.The pin_mass_refund utility aggregates the credit balance for each bill unit for each account and generates refund items for the aggregated credit amount.
The pin_refund utility retrieves the refund items for the accounts that use the SEPA payment method. For each bill unit, it records the payment details in the refund request (/sepa/ct) and sets the refund request status to Pending. You run the pin_refund utility after running the pin_mass_refund utility.
SEPA Credit Transfer refunds are applied to the accounts at the time refund requests are created (before refund requests are sent to the bank). The pin_refund utility calls the PCM_OP_PYMT_COLLECT opcode to apply the refunds and update the account's balance in the BRM database. If your bank is unable to process the refund, you reverse the refund recorded in BRM using the pin_sepa utility. For more information, see "Processing SEPA Response XML Files to Handle Failed Payment Transactions".
For more information about the pin_mass_refund and pin_refund utilities, see "About Refunds" in BRM Managing Accounts Receivable.
You run the pin_sepa utility to generate the SEPA request XML files. For more information about the utility syntax, see "pin_sepa".
Before running pin_sepa, configure the utility to provide the information it requires for generating the SEPA request XML files. For more information, see "Configuring the pin_sepa Utility for Generating and Processing SEPA XML Files".
The pin_sepa utility extracts payment details from the SEPA Direct Debit and SEPA Credit Transfer payment requests (created by the pin_collect and pin_refund utilities), which are in Pending status, from the BRM database into SEPA request XML files. All the payment transactions belonging to the same creditor are grouped in one file. The number of payment transactions in a file is configurable by using the infranet.threadpool.fetchsize entry in the Infranet.properties file for pin_sepa.
You must manually send the SEPA request XML files to your bank for collection of the payments. For more information, see "Sending the SEPA Request XML Files to Your Bank to Collect Payment".
After the SEPA request XML files are generated, BRM considers the payment as successful and changes the status of the payment requests to Requested. The payment requests remain in Requested status unless the payment is reversed for any reason.
Important:
The SEPA request XML files cannot be regenerated. You must ensure the files are protected from accidental loss or corruption.
The SEPA request XML files contain sensitive customer data. You must ensure the files are protected from unauthorized access.
For more information on security, see BRM Security Guide.
By default, the pin_sepa utility is not included in the pin_bill_day billing script. You can either add it to the daily billing script or run it separately; however, Oracle recommends to run pin_sepa daily for SEPA payment collection. You can run the pin_sepa utility manually or as a cron job that runs at specified times.
The SEPA request XML files are stored in the directory that you specify in the Infranet.properties file until they are delivered to your bank for collection of payment. You must manually send the files to your bank or payment processing center: BRM does not send the files.
After sending the files, ensure the files were successfully delivered to your bank. Potential revenue loss can occur if the SEPA request XML files that are generated in BRM are not received by your bank for processing.
Your bank sends back the SEPA response XML files with the payment transactions that are rejected. Your bank may reject a SEPA payment or refund request for reasons such as the following:
The payment or refund request contains an invalid IBAN or BIC.
The payment request contains an invalid or incorrect mandate.
The customer's bank account has insufficient funds to process the payment.
SEPA Direct Debit payments and SEPA Credit Transfer refunds are applied to the accounts in BRM at the time payment requests are created. Therefore, any payment transactions that are rejected by the bank needs to be reversed in BRM.
The SEPA response XML file indicates a status at the group level, payment-information level, and transaction level.
If the group-level status is Reject, all the payment transactions in the response file are rejected.
If the payment-information-level status is Reject, all the payment transactions in the payment information are rejected.
If the transaction-level status is Reject, only the payment for this transaction is rejected.
You run pin_sepa utility to process the rejected payments in the SEPA response file. For more information about the utility, see "pin_sepa". The utility automatically initiates the payment reversal in BRM. Using the payment transaction ID, BRM locates the corresponding SEPA payment request in the database and changes the status of the payment request to Reject.
To reverse a SEPA Direct Debit payment, BRM uses the PCM_OP_BILL_REVERSE opcode to reverse the payment from the account balance and to reopen the bills and items that were previously closed when the payment was applied.
To reverse a SEPA Credit Transfer refund, BRM uses the PCM_OP_AR_REVERSE_REFUND opcode to reverse the refund from the account balance and to reopen the refund items that were previously closed when the refund was applied.
An erroneous or duplicate payment occurs when your customer is billed twice for the same charge. The payment is recorded in BRM, and the payment transaction is successfully completed by the bank.
Unlike a payment reversal that occurs when a payment is rejected by the bank, duplicate payment reversals are not initiated by BRM.
To reverse a duplicate payment recorded in BRM, use the PCM_OP_BILL_REVERSE opcode. The PCM_OP_BILL_REVERSE opcode changes the status for the duplicate payment request to Reversed and creates a new payment reversal request (/sepa/dd/reversal).
After the payment reversal requests are created, you run the pin_sepa utility to generate the SEPA reversal request XML files. For more information about the utility syntax, see "pin_sepa". The pin_sepa utility extracts the payment details from the payment reversal requests, which are in Pending status, from the BRM database into SEPA reversal request XML files.
After the SEPA reversal request XML files are generated, BRM considers the payment reversal as successful and changes the status of the payment reversal requests to Requested.
You must manually send the SEPA reversal request files to your bank to reverse the charges from the customer's bank account.
For SEPA compliance, banks are required to use SEPA ISO20022 XML messages to exchange customer's payment information.
BRM supports the following ISO20022 XML messages:
For SEPA Credit Transfer:
Customer Credit Transfer Initiation (pain.001.001.03): This message transports the customer-to-bank credit transfer information sent by the customer (originator) to the customer's bank.
Customer Payment Status Report (pain.002.001.03): This message transports the credit transfer reject instruction between the bank and its remitting customer.
For SEPA Direct Debit:
Customer Direct Debit Initiation (pain.008.001.02): This message transports the direct debit collection instruction from the creditor to the creditor's bank.
Customer to Bank Payment Reversal (pain.007.001.02): This message transports the customer-to-bank reversal instruction for a collection sent by the creditor to the creditor's bank.
Bank to Customer Payment Status Report (pain.002.001.03): This message transports the direct debit reject instruction between the bank and its remitting customer.
You and your bank must use this version of ISO20022 XML message to ensure the messages sent and received are interpreted correctly.
The SEPA request and response XML files must comply with the XML schema definitions (XSD) that are provided in BRM.
Before processing a SEPA response file, BRM validates the contents using the XSD. BRM cannot process a response file that uses a different XSD.
You use the pin_sepa utility to generate the SEPA request XML files and to process SEPA response XML files.
Before running the pin_sepa utility, you must edit the utility's Infranet.properties file to include the information that it requires to generate and process SEPA request and response XML files.
To configure the Infranet.properties file:
Open the BRM_Home/apps/pin_sepa/Infranet.properties file in a text editor.
Provide the values listed in Table 3-2.
The Infranet.properties file for the pin_sepa utility includes standard configuration entries. See "Using Configuration Files to Connect and Configure Components" in BRM System Administrator's Guide for more information.
Table 3-2 pin_sepa Infranet.properties Configuration Entries
| Entry | Description |
|---|---|
|
infranet.connection |
Specifies the connection information to connect to the BRM database. |
|
infranet.login.type |
Specifies if a login name and password is required to connect to the BRM database. The default is 1. |
|
infranet.log.level |
Specifies the error reporting level. The default is 1.
|
|
infranet.log.file |
Specifies the file name used to log errors. The default is pin_sepa.pinlog. |
|
infranet.threadpool.size |
Specifies the number of threads. The default is 3. |
|
infranet.threadpool.maxsize |
Specifies the maximum number of threads. The default is 5. |
|
infranet.threadpool.fetchsize |
Specifies the number of records fetched from the BRM database and assigned to a thread at one point of time. This entry also controls the maximum number of payment transactions that can be in a SEPA request XML file. The default is 100. |
|
infranet.sepa_dd_req_dir.path |
Specifies the directory path to the SEPA Direct Debit request XML files. The default directory is BRM_Home/apps/pin_sepa/sepa_dd. If you change the default directory path, you must create the new directory where you want to store the files before running pin_sepa. |
|
infranet.sepa_ct_req_dir.path |
Specifies the directory path to the SEPA Credit Transfer request XML files. The default directory is BRM_Home/apps/pin_sepa/sepa_ct. If you change the default directory path, you must create the new directory where you want to store the files before running pin_sepa. |
|
infranet.sepa_rev_req_dir.path |
Specifies the directory path to the SEPA Direct Debit reversal request XML files. The default directory is BRM_Home/apps/pin_sepa/sepa_rev. If you change the default directory path, you must create the new directory where you want to store the files before running pin_sepa. |
|
infranet.sepa_resp_dir.path |
Specifies the directory path to the SEPA Direct Debit, Credit Transfer, and Direct Debit reversal response XML files. The default directory is BRM_Home/apps/pin_sepa/sepa_resp/input. If you change the default directory path, you must create the new directory where you want to store the files before running pin_sepa. The utility reads all the files in the directory for processing. Hence, it recommended to store only response XML files in this directory. |
|
infranet.sepa.sddrequest.ReqdColltnDt.pattern |
Specifies the date pattern for the SEPA Direct Debit request. |
|
infranet.sepa.sddrequest.ReqdColltnDt.value |
Specifies the date on which to collect the money from the customer. |
|
infranet.sepa.sddrequest.InitgPty.Nm |
Specifies the name of the party initiating the SEPA Direct Debit request. |
|
infranet.sepa.sddrequest.InitgPty.OrgId |
Specifies the ID of the party initiating the SEPA Direct Debit request. |
|
infranet.sepa.sddrequest.PmtInf.PmtMtd |
Specifies the SEPA Direct Debit payment method. This entry must be set to DD. |
|
infranet.sepa.sddrequest.InstrPrty |
Specifies the instruction priority for the SEPA Direct Debit request. The default is NORM. |
|
infranet.sepa.sddrequest.ChrgBr |
Specifies the party who will pay for the charges. The default is SLEV. According to the SEPA Rulebook, the only value allowed for this entry is SLEV. |
|
infranet.sepa.sddrequest.PmtTpInf.LclInstrm |
Specifies the Local instrument code for SEPA Direct Debit request. The default is CORE.
|
|
infranet.sepa.sddrequest.PmtTpInf.SvcLvl |
Specifies the service level for the SEPA Direct Debit request. The default is SEPA. |
|
infranet.sepa.sctrequest.PmtInf.PmtMtd |
Specifies the SEPA Credit Transfer payment method. This entry must be set to TRF. |
|
infranet.sepa.sctrequest.ReqdExctnDt.pattern |
Specifies the date pattern for the SEPA Credit Transfer request. |
|
infranet.sepa.sctrequest.ReqdExctnDt.value |
Specifies the date on which to credit the money to customer account. |
|
infranet.sepa.sctrequest.InstrPrty |
Specifies the instruction priority for SEPA Credit Transfer request. The default is NORM. |
|
infranet.sepa.sctrequest.ChrgBr |
Specifies the party who will pay for the charges. The default is SLEV.According to the SEPA Rulebook, the only value allowed for this entry is SLEV. |
|
infranet.sepa.sctrequest.InitgPty.Nm |
Specifies the name of the party initiating the SEPA Credit Transfer request. |
|
infranet.sepa.sctrequest.InitgPty.OrgId |
Specifies the ID of the party initiating the SEPA Credit Transfer request. |
|
infranet.sepa.sctrequest.PmtTpInf.LclInstrm |
Specifies the Local instrument code for SEPA Credit Transfer request. The default is CORE.
|
|
infranet.sepa.sctrequest.PmtTpInf.SvcLvl |
Specifies the service level for the SEPA Credit Transfer request. The default is SEPA. |
|
infranet.sepa.sddreversal.InitgPty.Nm |
Specifies the name of the party initiating the SEPA Direct Debit Reversal request. |
|
infranet.sepa.sddreversal.InitgPty.OrgId |
Specifies the ID of the party initiating the SEPA Direct Debit Reversal request. |
Save and close the file.
The following sections describe how BRM handles mandate information.
To register the mandate information provided during customer registration, BRM uses the PCM_OP_CUST_SET_PAYINFO opcode.
PCM_OP_CUST_SET_PAYINFO takes as input the mandate information such as the customer's IBAN and BIC and the creditor identification code.
This opcode adds the mandate by:
Creating a unique mandate reference number (UMR) for the mandate, if it is not provided in the input flist
Setting the status of the mandate to active
Creating the /payinfo/sepa object with the mandate information
The PCM_OP_CUST_SET_PAYINFO opcode calls PCM_OP_CUST_CREATE_PAYINFO, which calls the PCM_OP_CUST_POL_VALID_PAYINFO policy opcode, which validates that the format of the IBAN and BIC comply with the formats described in the SEPA rulebooks. Additional custom validations can be performed on the mandate information, such as country-specific validations.
To update the mandate information, BRM uses the following opcodes:
PCM_OP_CUST_AMEND_MANDATE, to update the customer information
PCM_OP_CUST_AMEND_CREDITOR_INFO, to update the creditor information
PCM_OP_CUST_AMEND_MANDATE takes as input a reference to the /payinfo/sepa object and the mandate information to update.
This opcode updates the mandate by:
Updating the /payinfo/sepa object with the new mandate information
Updating the PIN_FLD_MANDATE_AMENDED field in the /payinfo/sepa object by using flags to indicate the fields that are amended
Generating the /event/activity/sepa/mandate_amendment event to record the mandate update
PCM_OP_CUST_AMEND_CREDITOR_INFO takes as input the creditor ID to be updated and the new creditor ID and creditor name.
This opcode updates the creditor information by:
Updating the /config/creditor object with the new creditor information
Determining if any /payinfo/sepa object exists that is associated with the original creditor ID and updating the /payinfo/sepa object with the new creditor information
In each /payinfo/sepa object that is updated, updating the PIN_FLD_MANDATE_AMENDED field by using flags to indicate the fields that are amended
Generating the /event/activity/sepa/mandate_amendment event to record the update
To cancel a mandate, BRM uses the PCM_OP_CUST_CANCEL_MANDATE opcode.
PCM_OP_CUST_CANCEL_MANDATE takes as input the reference to the /payinfo/sepa object that contains the mandate to cancel.
This opcode cancels the mandate by:
Setting the PIN_FLD_MANDATE_STATUS field in the /payinfo/sepa object to PIN_MANDATE_STATUS_CANCELED
Setting the PIN_FLD_MANDATE_END_T field to the current time to record the time of cancellation
Calling the PCM_OP_CUST_DELETE_PAYINFO opcode to delete the /payinfo/sepa object. The opcode does not cancel the /payinfo/sepa object if it determines that it is associated with a bill unit or if a SEPA payment request is pending