How to add a payment gateway module

Payment methods integrate BILLmanager with external payment systems. The payment system module is responsible for:

• a set of connection settings;
• the appearance of the settings form;
• the appearance and behavior of the payment form on the client side.

The payment system module also implements mechanisms for invoicing, processing, and crediting payments from the client. The module's logic during payment depends on requirements. The following can be implemented:

• redirecting the client to the payment system website for payment;
• issuing an invoice and waiting for the client to make the payment.

General information

Installation directory: /usr/local/mgr5/paymethods/
XML description: /usr/local/mgr5/etc/xml/billmgr_mod_pm<name>.xml

Management: main module script (pmXXX) and CGI scripts.

The main module pm<name> is called only by BILLmanager. The module has no data about the user's browser and does not return HTML code. Module tasks:

• inform BILLmanager about supported features (--command config);
• configure and validate payment method parameters (pmtune, pmvalidate);
• perform payment without redirect or perform preparatory actions before redirect (crset);
• check payment status ( checkpay);
• perform refund or transfer of funds (rfset, tfset).

CGI scripts are called from the user's browser or payment system via HTTP. They work like regular web pages and can output HTML code. CGI script tasks:

• redirect the user to the payment system payment page (payment_script);
• receive a notification (webhook) from the payment system about payment status change and call payment.setpaid (result script);
• show the card binding page for auto-payments (recurring_script).

CGI scripts are optional — if all logic is implemented in the main module (for example, payment by issued invoice without redirect), they may be absent. For more details, see section Module CGI scripts.

Module operation mechanism

Stages of working with the payment system module in BILLmanager:

1. Initial configuration:
   1. Module installation.
   2. Adding a connection to the payment system.
2. Payment processing workflow:
   1. Client creates a payment.
   2. Client pays the issued invoice.
   3. Crediting or cancellation of the payment.

Install the module:

• manually, if it is provided as a set of files;
• from the standard repository using a package manager.

After installation, the module becomes available for selection when creating a payment method in BILLmanager.

The platform polls each module at startup to learn about supported features and required parameters. This speeds up operation: unsupported calls are excluded and form behavior is determined when the client makes a payment.

Module structure

A payment system module consists of two or more files. The main files are the module XML description and the script that passes the module configuration to the platform. Usually two CGI scripts are used: for redirecting the client to the payment system website and for receiving notifications about payment status changes from the payment system.

If the payment system has additional integration requirements, other files may be added. For example, files responsible for rendering additional forms, additional payment parameter checks, printing receipts, checking payment statuses on schedule, etc.

The standard set of module files looks as follows:

Where XXX is the module name specified in Latin characters. If the name of the main module script contains a file extension, it is also included in the module name. For example, if your script is named pmpay.php, then the module name is pay.php, not pay.

XML description

The file name must be in the format billmgr_mod_pmXXX.xml, where XXX is the module name. The file must be copied to the directory /etc/xml relative to the BILLmanager installation path. The file contains a description of the module itself (described as a plugin), as well as descriptions of additional forms and messages.

<mgrdata>
  <plugin name="XXX">
    <group>payment_method</group>
    <msg name="desc_short" lang="ru">XXX module</msg>
    <msg name="desc_short" lang="en">XXX module</msg>
    <msg name="desc_full" lang="ru">XXX module</msg>
    <msg name="desc_full" lang="en">XXX module</msg>
  </plugin>

  <metadata name="paymethod.edit.XXX" type="form">
    <form>
      <page name="methodprops">
        <field name="prop1">
          <input name="prop1" required="yes" type="text" />
        </field>
        <field name="prop2">
          <input name="prop2" private="yes" required="yes" type="text" />
        </field>
      </page>
      <page name="recurring">
        <field name="recurring">
         <input type="checkbox" name="recurring">
           <if value="off" hide="recurringprop1"/>
           <if value="off" hide="recurringprop2"/>
         </input>
        </field>
        <field name="recurringprop1">
          <input name="recurringprop1" required="yes" type="text" />
        </field>
        <field name="recurringprop2">
          <input name="recurringprop2" private="yes" required="yes" type="text" />
        </field>
      </page>
      <page name="refundpage">
        <field name="allowrefund">
         <input type="checkbox" name="allowrefund">
           <if value="off" hide="refundprop1"/>
           <if value="off" hide="refundprop2"/>
         </input>
        </field>
        <field name="refundprop1">
          <input name="refundprop1" required="yes" type="text" />
        </field>
        <field name="refundprop2">
          <input name="refundprop2" private="yes" required="yes" type="text" />
        </field>
      </page>
    </form>
  </metadata>

  <metadata name="payment.edit.XXX" type="form">
    <form>
      <field name="payment_prop">
        <input type="text" name="payment_prop" required="yes"/>
      </field>
    </form>
  </metadata>

  <metadata name="paymethod.transfer.XXX" type="form">
    <form>
      <field name="param">
        <input type="text" name="param" required="yes"/>
      </field>
    </form>
  </metadata>

  <lang name="en">
    <messages name="label_paymethod">
      <msg name="pmXXX">XXX module</msg>
      <msg name="module_pmXXX">XXX module</msg>
    </messages>

    <messages name="paymethod.edit.XXX">
      <msg name="prop1">Prop 1</msg>
      <msg name="hint_prop1">Hint for prop 1</msg>
      <msg name="prop2">Prop 2</msg>
      <msg name="hint_prop2">Hint for prop 2</msg>

      <msg name="recurringprop1">Recurring prop 1</msg>
      <msg name="hint_recurringprop1">Hint for recurring prop 1</msg>
      <msg name="recurringprop2">Recurring prop 2</msg>
      <msg name="hint_recurringprop2">Hint for recurring prop 2</msg>

      <msg name="refundprop1">Refund prop 1</msg>
      <msg name="hint_refundprop1">Hint for refund prop 1</msg>
      <msg name="refundprop2">Refund prop 2</msg>
      <msg name="hint_refundprop2">Hint for refund prop 2</msg>
    </messages>

    <messages name="paymethod.transfer.XXX">
      <msg name="param">Param</msg>
      <msg name="hint_param">Hint param</msg>
    </messages>

    <messages name="payment.edit.XXX">
      <msg name="payment_prop">Prop</msg>
      <msg name="hint_payment_prop">Hint for prop</msg>
      <msg name="placeholder_payment_prop">prop</msg>
    </messages>
  </lang>

  <lang name="ru">
     <messages name="label_paymethod">
      <msg name="pmXXX">XXX module</msg>
      <msg name="module_pmXXX">XXX module</msg>
    </messages>

    <messages name="paymethod.edit.XXX">
      <msg name="prop1">Property 1</msg>
      <msg name="hint_prop1">Hint for property 1</msg>
      <msg name="prop2">Property 2</msg>
      <msg name="hint_prop2">Hint for property 2</msg>
    </messages>

    <messages name="paymethod.transfer.XXX">
      <msg name="param">Parameter</msg>
      <msg name="hint_param">Hint for parameter</msg>
    </messages>

    <messages name="payment.edit.XXX">
      <msg name="payment_prop">Property</msg>
      <msg name="hint_payment_prop">Hint for property</msg>
      <msg name="placeholder_payment_prop">property</msg>
    </messages>
  </lang>
</mgrdata>

The <plugin> element is responsible for describing the module itself. The name property matches the name of the payment system module. Inside the element there can be one group element with the value payment_method, which indicates that this module is used for payment methods, and several msg elements. The lang property in the element indicates which language the message belongs to; the name attribute can have the following values:

• desc_short — brief module description. Displayed when selecting a module in BILLmanager;
• desc_full — full module description. Displayed when building a list of installed modules in COREmanager.

The metadata element with the name paymethod.edit.XXX is responsible for additional module fields when adding and configuring a payment method. Formed according to the standard XML form description. Place fields in the element <page name="methodprops"></page> for correct placement of fields on forms in BILLmanager. The private attribute is supported, which prohibits output of this attribute in XML when printing an invoice for a created payment. Used for secret data, such as a password or secret key. The element recurring describes recurring payment settings, the element refundpage — payment cancellation settings.

The metadata element with the name payment.edit.XXX is responsible for additional fields that the client sees when making a payment. Described according to the standard scheme for XML forms in BILLmanager. For more details, see the article Modules. General principles.

The metadata element with the name paymethod.transfer.XXX is responsible for additional fields displayed when transferring funds back to the client. Described according to the standard XML form description scheme in BILLmanager.

The lang element contains translations of field names on the form according to the standard translation description scheme. The section <messages name="label_paymethod"> is responsible for the payment system module name label in the payment methods list.

Main module script

The main payment system module script passes information to the platform about supported functions and processes some of them. When working with the module, BILLmanager executes the script file with the following parameters:

paymethods/pmxxx --command cmd [--payment id [--amount amnt]]

Where:

• cmd — control command;
• id — payment code;
• amnt — amount in the payment method currency (used for refund and transfer of funds).

Required command:

• config — returns an XML file with <feature> (list of supported features) and <param> (paths to CGI scripts or recurring).

Main commands (called depending on declared <feature>):

• pmtune or pmvalidate — configuration and validation of payment method parameters;
• crtune or crvalidate or crset — payment form configuration, data validation, payment execution;
• crdelete — payment deletion;
• rftune or rfvalidate or rfset — configuration, validation and execution of refund (refund);
• tftune or tfvalidate or tfset — configuration, validation and execution of transfer (transfer);
• rctune or rcvalidate or rcset or rcpay or rcdelete — recurring (automatic) payments (recurring);
• checkpay — checking payment status.

Possible <feature> in config response:

• refund;
• transfer;
• recurring;
• redirect;
• noselect;
• notneedprofile;
• pmtune;
• pmvalidate;
• crtune;
• crvalidate;
• crset;
• crdelete;
• rftune;
• rfvalidate;
• rfset;
• tftune;
• tfvalidate;
• tfset;
• rctune;
• rcvalidate;
• rcset;
• rcpay;
• rcdelete.

/usr/local/mgr5/paymethods/pmnowpayments --command config

Explanations for the XML file

The following values can be passed to the --command parameter:

• config — module configuration request. In response, the module must return an XML document to standard output:
  
  Example XML document

  Example XML document

  <doc>
  	<feature>
  		<refund>on</refund>
  		<recurring>on</recurring>
  		<redirect>on</redirect>
  		<crset>on</crset>
  	</feature>
  	<param>
  		<payment_script>/mancgi/pullpayment.php</payment_script>
  		<recurring_script>/mancgi/pullrecurring.php</recurring_script>
  		<recurring_type>20</recurring_type>
  	</param>
  </doc>

The feature element contains a list of payment system module capabilities. If a capability is not supported, it should not be present in the command execution result output.

List of allowed values:

• refund — indicates support for payment cancellation, refund of funds. Without this capability, processing of commands rftune, rfvalidate, rfset is not required;
• transfer — indicates support for transferring funds from an account in the payment system to the client's account. Without this capability, processing of commands tftune, tfvalidate, tfset is not required;
• recurring — indicates support for recurring payments. Without this capability, the parameters recurring_script and recurring_type can be omitted;
• redirect — indicates that to make a payment using the payment system, the module will redirect the client to the payment system;
• noselect — the payment method will not be displayed in the list when selected by the client. Used when preliminary creation of a payment in BILLmanager is not required for payment. For example, when paying through a terminal;
• notneedprofile — specified if specifying the payer is not mandatory for making a payment. However, if the payment method is connected to a company, the system will request the client to create or select a payer;
• pmtune — specified if additional actions are needed to correctly display the payment method settings form. For more details, see the description of the pmtune command;
• pmvalidate — if specified, when saving payment method parameters, the module will be called to validate the entered values;
• crtune — specified if additional actions are required to correctly display the payment form. For more details, see the description of the crtune command;
• crvalidate — if specified, when saving values entered by the client, the module will be called for validation ;
• crset — specified if:
  • before redirecting to payment, the module needs to perform any actions;
  • payment is made without redirecting to the payment system;
  • client data entry is required during payment;
• crdelete — specified if actions on the payment system side are necessary for correct payment deletion;
• rftune — similar to crtune, but for refunds;
• rfvalidate — similar to crvalidate, but for refunds;
• rfset — required capability for refunds. When the command is called, the module performs all necessary actions for the refund;
• rctune — similar to crtune, but for recurring payments;
• rcvalidate — similar to crvalidate, but for recurring payments;
• rcset — similar to crset, but when configuring recurring payments from the client side. Used for configuring recurring payments on the payment system side;
• rcpay — called when creating a recurring payment in BILLmanager. Used to invoke payment on the payment system side;
• rcdelete — specified if actions on the payment system side are necessary for correct auto-payment profile deletion;
• tftune — similar to crtune, but for transfers;
• tfvalidate — similar to crvalidate, but for transfers;
• tfset — required capability for transfers. When the command is called, the module performs all necessary actions for the transfer;
• checkpay — BILLmanager call to check payment status in the external system.

BILLmanager passes script paths via the config command response in the <param> section. BILLmanager uses these paths to form links that the user's browser or payment system will use to access the scripts.

The param element contains a list of payment method parameters. Supported:

• payment_script — path to the payment redirect script relative to the BILLmanager installation domain. For example, if the script is located at http://domain.com/cgi/pullpayment.php , specify /mancgi/pullpayment.php;
• recurring_script — path to the redirect script for confirming recurring payment activation. For example, if the script is located at http://domain.com/cgi/pullrecurringpayment.php , specify /mancgi/pullrecurringpayment.php;
• recurring_type — bitmask of supported recurring payment capabilities. Each item below corresponds to a bit position: to get the flag value, shift 1 left by the specified number of positions (1 << N). The final parameter value is the result of combining the required flags via bitwise OR.
  • 1 (value 2) — payment is created separately for each service;
  • 2 (value 4) — payment is created for multiple services;
  • 7 (value 128) — payment is created for all services;
  • 8 (value 256) — specifying a maximum amount is required to register the payment;
  • 20 (value 1 048 576) — redirect to the payment system is required to confirm the recurring payment;
  • 21 (value 2 097 152) — additional client actions are required for confirmation.

• Example

  For example, to specify that payment is created separately for each service (position 1) and redirect is required for confirmation (position 20), you need to shift one left by 1 and by 20 bits, then combine the results via bitwise OR:

  (1 << 1) | (1 << 20) = 2 | 1 048 576 = 1 048 578.

  The final value for the recurring_type parameter in this case is 1 048 578.

*tune (pmtune, crtune, rftune, tftune, rctune) — input and output

Input — standard BILLmanager XML form.
Output — modified form XML file.

*validate (pmvalidate, crvalidate, rfvalidate, tfvalidate, rcvalidate) — input and output

Input: XML form with data entered by the user on the form.

<doc>
<field1>value1</field1>
<field2>value2</field2>
</doc>

Output: on success — <doc/>; on error — error XML form.

rfset — input (stdin)

Accepts data about the original payment or the payment created for refund. For example:

• refund amount;
• description of the refund reason;
• payment method parameters.

	<doc>
		<!-- Payment identifier. -->
		<payment>100500</payment>

	<!-- Payment method identifier. -->
	<paymethod>25</paymethod>

		<!-- Refund amount in payment method currency. -->
	<payment_paymethodamount>-250.00</payment_paymethodamount>

	<!-- Payment description. -->
	<payment_description>Refund for order #12345</payment_description>

	<!-- Additional payment method parameters. -->
	<paymethod_xmlparams>
		...
	</paymethod_xmlparams>

	<!-- Payment method currency. -->
	<paymethod_currency>RUB</paymethod_currency>

	<!-- Original payment for which refund or transfer is made. -->
	<source_payment>5001</source_payment>	

	<!-- Additional user data.-->
	<user_field>custom_value</user_field>
</doc>

tfset — input (stdin)

Accepts data about the payment created for transfer. For example:

• transfer amount;
• payment method parameters.

	<doc>
		<!-- Payment identifier. -->
		<payment>100500</payment>

	<!-- Payment method identifier. -->
	<paymethod>25</paymethod>

		<!-- Transfer amount in payment method currency. -->
	<payment_paymethodamount>-250.00</payment_paymethodamount>

	<!-- Payment description. -->
	<payment_description>Transfer for order #12345</payment_description>

	<!-- Additional payment method parameters. -->
	<paymethod_xmlparams>
		...
	</paymethod_xmlparams>

	<!-- Payment method currency. -->
	<paymethod_currency>RUB</paymethod_currency>

	<!-- Original payment for which transfer is made. -->
	<source_payment>5001</source_payment>	

	<!-- Additional user data.-->
	<user_field>custom_value</user_field>
</doc>

Module CGI scripts

CGI scripts are an optional part of the payment system module. They may be absent if all logic is implemented in the main module. For example, when paying via a YMoney wallet, the invoice is issued to the user by the main module script and its payment is checked on schedule.

Cases are also possible when the module contains several CGI scripts:

• payment;
• receiving notifications about payment status changes;
• other scripts required by the payment system.

For example, for integration with YMoney, an additional CGI script has been implemented that verifies client-entered data on the YMoney side. For this, the payment system calls the script and passes the client-entered data to it, as well as a parameter responsible for the operation type — check.

CGI scripts can be located on a server different from BILLmanager, or on a different IP address or domain. It all depends on the requirements of the module developer and the payment system. For example, there are schemes where authorization when sending a notification about payment status change is performed via a client certificate. In this case, the script must be placed on a separate VirtualHost with client certificate processing configuration. If there is no specific integration requirement, to simplify payment system module support, it is recommended to place CGI scripts in the standard BILLmanager directory — /usr/local/mgr5/cgi

Payment redirect script

The payment script (payment_script) receives the parameter elid (payment identifier) via HTTP request. Using the payment.info function, the script requests data necessary for forming the payment form. The standard method is automatic form submission when the page loads:

<html>
  <head>
    <meta http-equiv='Content-Type' content='text/html; charset=UTF-8' />
    <link rel='shortcut icon' href='billmgr.ico' type='image/x-icon' />
    <script language='JavaScript'>
      function submit() {
        document.frm.submit();
      }
    </script>
  </head>
  <body onload='submit()'>
    <form name='frm' action='https://paysystem/url' method='post'>
      <input type='hidden' name='shop_id' value='1'>
      <input type='hidden' name='amount' value='1.00'>
    </form>
  </body>
</html>

The function returns a response in XML format or JSON:

<doc>
  <payment>                                                   <!-- Payment information -->
    <id>1</id>                                                <!-- Payment code -->
    <subaccount>1</subaccount>                                <!-- Client account code -->
    <paymethod>1</paymethod>                                  <!-- Payment method code -->
    <recipient/>                                              <!-- Recipient company code. If present, company data is also added to the function output -->
    <sender/>                                                 <!-- Payer code on whose behalf the payment is made. If present, payer data is also added to the function output -->
    <subaccountamount>1.00</subaccountamount>                 <!-- Payment amount in account currency -->
    <status>2</status>                                        <!-- Payment status -->
    <number>pfx/1</number>                                    <!-- Payment number -->
    <paymethodamount>1.00</paymethodamount>                   <!-- Payment amount in payment method currency -->
    <currency>126</currency>                                  <!-- Payment amount currency code -->
    <externalid/>                                             <!-- External payment code, can be saved by payment.setpaid function -->
    <description>Advanced payment</description>               <!-- Payment purpose description -->
    <remote_ip>127.0.0.1</remote_ip>                          <!-- IP address from which the payment was created-->
    <manager_url>https://localhost:1500/billmgr</manager_url> <!-- URL from which BILLmanager was opened when creating the payment -->
    <phone>7 000 0000000</phone>                              <!-- Additional payment parameter, specified in module XML files -->
    <useremail>email@example.com</useremail>                  <!-- email address of the user making the payment-->
    <paymethod>                                               <!-- Payment method information -->
      <id>1</id>                                              <!-- Payment method code -->
      <name>XXX</name>                                        <!-- Payment method name -->
      <active>on</active>                                     <!-- Status -->
      <minamount>0.00</minamount>                             <!-- Minimum payment amount -->
      <maxamount/>                                            <!-- Maximum payment amount -->
      <autoclearperiod/>                                      <!-- Auto-deletion period for unpaid payments -->
      <currency>126</currency>                                <!-- Payment method currency code -->
      <profiletype>1,2,3</profiletype>                        <!-- Payer types that can use the payment method -->
      <commissionamount>0.00</commissionamount>               <!-- Commission amount when paying -->
      <commissionpercent>0</commissionpercent>                <!-- Commission percentage when paying -->
      <module>pmXXX</module>                                  <!-- Module name -->
    </paymethod>
    <currency>                                                <!-- Information about the currency in which the payment is made-->
      <id>126</id>                                            <!-- Currency code from the directory -->
      <name>Russian Ruble</name>                              <!-- Name -->
      <iso>RUB</iso>                                          <!-- Letter currency code according to ISO-->
      <code>643</code>                                        <!-- Numeric currency code according to ISO -->
      <active>on</active>                                     <!-- Status -->
    </currency>
    <project>                                                 <!-- Provider information -->
      <id>1</id>                                              <!-- Code -->
      <name>ISPsystem</name>                                  <!-- Name -->
      <notifyemail>email@example.com</notifyemail>            <!-- email for notifications -->
    </project>
    <items>                                                   <!-- List of invoice items, when binding payment to an order contains ordered services, otherwise payment purpose description -->
      <item>                                                  <!-- Invoice item -->
        <name>Advanced payment</name>                         <!-- Name -->
        <locale_name>Advanced payment</locale_name>           <!-- Name in user localization -->
        <amount>1.00</amount>                                 <!-- Amount per item -->
      </item>
    </items>
  </payment>
</doc>

Additional parameters that clients need to specify when paying are added to the payment element. All payment method parameters are added to the paymethod element. This method of obtaining payment information excludes direct access to the BILLmanager database.

Script for receiving notifications about payment status changes

The script for processing notifications about payment status changes from the payment system accepts an HTTP request from the payment system (webhook), verifies the signature, checks the data and calls one of the payment status change functions:

Result script algorithm:

1. Extracts the payment code from data received from the payment system in BILLmana ger.
2. By payment code, obtains information about the payment and payment method parameters:
   • from the database;
   • using the payment.info function.
3. Compares data received from the payment system with data stored in BILLmanager.
4. If the received data has a control signature, verifies it using the secret key.
5. Changes the payment status in BILLmanager according to the received data using one of the functions described below.
6. If necessary, notifies the payment system about successful or unsuccessful processing of the incoming request.

Other CGI scripts

The recurring payments script (recurring_script) shows the user the card binding page. After successful binding, it saves the token and passes it to BILLmanager.

BILLmanager functions

Return pages

After making a payment, standard functions are used to return the client to BILLmanager:

To supplement the forms displayed by the functions, specify in the plugin XML description:

<metadata name="payment.XXX.success" type="form">
<form>
<field name="success_description" noname="yes" formwidth="yes">
<textdata name="success_description"/>
</field>
</form>
</metadata>
<metadata name="payment.XXX.fail" type="form">
<form>
<field name="fail_description" noname="yes" formwidth="yes">
<textdata name="fail_description"/>
</field>
</form>
</metadata>

Module example

The example illustrates implementation of a payment system module using the PULL (REST) protocol.

PHP

The module consists of the following main files:

• etc/xml/billmgr_mod_pmpull.php.xml — XML description;
• paymethods/pmpull.php — main script;
• cgi/pullpayment.php — CGI script for redirecting to payment;
• cgi/pullresult.php — CGI script for receiving notifications from the payment system.

And also an auxiliary file:

• include/php/bill_util.php

bill_util.php functions

Before including the bill_util.php file in your script, you must define the macro __MODULE__ to form the log file name.

set_include_path(get_include_path() . PATH_SEPARATOR . "/usr/local/mgr5/include/php"); 
define('__MODULE__', "pmXXX"); 
require_once 'bill_util.php';

The bill_util.php file provides the following functions:

• Debug($str) — outputs $str as additional information to the log;
• Error($str) — outputs $str as an error message to the log;
• LocalQuery($function, $param, $auth = NULL) — executes the $function function in BILLmanager, passing it parameters from the $param array and session code from $auth;
• HttpQuery($url, $param, $requesttype = "POST", $username = "", $password = "", $header = array("Accept: application/xml")) — performs a request to $url with parameters from $param, using request type $requesttype and authorization data from $username and $password. Additional headers can also be passed in $header;
• CgiInput($skip_auth = false) — receives an array of parameters received by the script in the query string or POST data. The $skip_auth parameter is responsible for receiving the auth parameter from cookies if it is absent in the received data;
• ClientIp() — receives the IP address from which the script was called;
• class Error — defines an error class that mimics error behavior in COREmanager.

C++ (using BILLmanager libraries)

In addition to the provided example, you can study examples from the BILLmanager developer package. BILLmanager contains libraries necessary for working with modules in C++. To develop your own processing modules:

1. Connect to the server with the platform via SSH. For more details on connecting via SSH, see the article Workstation setup.
2. Install the software package:

apt-get install billmanager-corporate-dev

dnf install billmanager-corporate-devel

After installation, the package contents will be available in the following directories:

C++

An example module is located at https://github.com/ISPsystemLLC/interkassa. The module uses COREmanager and BILLmanager header files, and is based on examples of building custom components described in the articles How to build custom components and Lower-level interaction, C++ plug-ins.

Also, when writing modules, materials from the developers section of the BILLmanager documentation may be useful.

Module structure

The module consists of required files:

• pminterkassa.cpp — code of the main executable file of the payment system module;
• xml/billmgr_mod_pminterkassa.xml — module XML description.

The module also includes CGI scripts:

• script for redirecting to payment in the processing center;
• script for receiving notifications about payment crediting.