Sorry - either this article does not exist or you haven't been given permission to view it.

TRUSTLY Integration Setup

This is an integration to make a payment in orm system. 

  1. In config_3rdparty.json copy the variable TRUSTLY_CONFIG from the general 
  2. In the custom TRUSTLY_CONFIG  fill the fields as follows:  

        " TRUSTLY_CONFIG " :  { 

            "enabled" :  true, 

            "test_mode" :  true, 

            "base_uri" :  "", 

            "logging_file" :  "trustly_payment_logs.log", 

            "submitUrl" :  "/orm/trustlyPayment/submit", 

           "notify_uri" :  "{domain}/orm/trustlyPayment/paymentNotification", 

            "success_url" :  "/orm/trustlyPayment/success ", 

            "failure_url" : "/orm/trustlyPayment/failure", 

            "username" :  "", 

            "password" :  "", 

            "client_private_key" :  "/path/trustly_private_key.pem", 

            "trustly_public_key" :  "/path/trustly_public_key.pem", 


    In config_orm this payment method now needs to be added/enabled for it to be available in ORM/Apps.

    In order to make sure the backend code (MTMS and RWS) and the frontend (App) code are in sync such that they are compatible and will work correctly without any issues, we need to have a mechanism of keeping the 2 sides in sync. In order to do this we need to implement a method of having the version number on both sides and being able to check if the 2 sides are in sync with each other such that there will not be any issues. There are different scenarios:

    1. App and backend are fully in sync with each other.
    2. Backend is ahead of app but there is no compatibility issue so app will work.
    3. Backend is ahead of app such that they are not compatible and that app will break.
    4. App is ahead of backend such that functionality in the app cannot be provided by the backend and therefore app will break.

    In order to be able to handle all the above scenarios, the following needs to be implemented:

    1. On MTMS code, we add a RWS version using semantic versioning (major.minor.patch) e.g. 2.2.3.
    2. Everytime there is change to the RWS, we update this version in MTMS. If it's a backwards compatible change then update the minor or patch version. If it's not backwards compatible then update the major version number.
    3. On RWS response (to either certain method or all methods?) add the version of the RWS running on the backend (where exactly?).
    4. On the app, add a new parameter that stores the version of the RWS API that this app works with.
    5. On app startup, compare the RWS version from the backend and the version on the app for compatibility.
    6. If they are compatible (e.g. RWS version = 2.2.0, app version = 2.1.1) then sweeeeet. If they are not compatible (e.g. RWS version = 3.1.6, app version = 2.1.1) then we have a problem!
    7. Show message to user on app that they need to update their app in cases of version incompatibility. Check if new version of app is available on app store and direct user to doing an update if available. If new version is not available then the message still tells the user that there is an incompatibility.

    The default behaviour of the TwoFactorEmailService and TwoFactorSMSService classes is to send an email or sms with "login" mentioned in the content body, because that's what 2FA was implemented for initially.

    We are now able to customise the emal/sms content body for non-login-related 2FA operations. The way to do that is as follows.


    Note: we do not create new template files to send a different content body; we simply change the relevant strings within.

    The private sendMail function in TwoFactorEmailService receives as optional parameters (in addition to other parameters) $langFileKeyOfCodeInfoInEmailBody and $langFileKeyOfCodeInstructionInEmailBody.

    Any public function in TwoFactorEmailService that calls the private sendMail function may pass values for these two optional parameters, which must have corresponding entries in lang.en.


    The value for $langFileKeyOfCodeInfoInEmailBody could be ''

    The value for $langFileKeyOfCodeInstructionInEmailBody could be ''

    In the lang.en file you would have:

    '' => 'Please find below the two factor authentication code required to confirm wallet credit or debit operations.',
    '' => 'Please provide this code to the agent to confirm the credit or debit operation to your wallet.',


    The private sendSMS function in TwoFactorSMSService receives as an optional parameter (in addition to other parameters) $applicationTextsKeyOfSMSBody.

    Any public function in TwoFactorSMSService that calls the private sendSMS function may pass a value for this optional parameter, which must have a corresponding entry in libs/texts/application_texts_default.php


    The value for $applicationTextsKeyOfSMSBody could be 'sms.two_factor_authentication_code_confirmation''

    In the application_texts_default.php file you would have:

    $APPLICATION_TEXTS['sms']['two_factor_authentication_code_confirmation'] = "Your %COMPANY_NAME% confirmation code is %CODE%";
    The following entries already exist in application_texts_default.php
    $APPLICATION_TEXTS['sms']['two_factor_authentication_code'] = "Your %COMPANY_NAME% login code is %CODE%";
    $APPLICATION_TEXTS['sms']['two_factor_authentication_code_confirmation'] = "Your %COMPANY_NAME% confirmation code is %CODE%";
    $APPLICATION_TEXTS['sms']['two_factor_authentication_code_generic_2fa'] = "Your %COMPANY_NAME% 2FA code is %CODE%";
    $APPLICATION_TEXTS['sms']['two_factor_authentication_code_generic_otp'] = "Your %COMPANY_NAME% OTP code is %CODE%";
    $APPLICATION_TEXTS['sms']['two_factor_authentication_code_generic_otp_long'] = "Your %COMPANY_NAME% one time password is %CODE%";

    Support Desk

    We have a dedicated in-house support team ready to help with all your enquiries on any of our products.

    •          Application & Services - All products in our RemitONE suite.
    •          Accounts & Billing - Get help with your accounts, subscriptions and payments.

    Our technical support team are readily available to help with all your Money Transfer Engine (MTE) related issues and enquiries. They can be reached via the following contact:

    Online Helpdesk:

    Telephone: +44 (0)20 8099 5795

    Telephone support is provided to customers on Professional & Enterprise Editions only, please consult your agreement if you are unsure if you qualify for telephone support.



    This article (attachment) explains in depth how our billing function operates and to give examples of how transaction and support incident costs are calculated, our customisation (bespoke development) payment and delivery process and how we allocate your payments made to us. The final sections cover how and when we send out reminders, suspension of service (due to non-payment), late payment fees, disputed items and VAT charges.

    Please read this article carefully. If you have any questions regarding this article or your business circumstances please feel free to contact

    To make any fields display or required based on your own needs please follow the information below.

    Go to the ARM > Settings > System Configuration Settings > Configuration Classification : UI > Expand "Field Settings"

    Just a little recap about the configuration UI settings -

    1- the whole system looks at  This includes the ARM, ORM and RWS.

    2- The ORM and RWS then look at for any overrides. If you change anything in point 1 and it doesn't reflect on the apps/ORM then you will need to change it here as well.

    3- For any country overrides you will need to add them to . "Country Name-Destination" for the ARM , "ORM-Country Name-Destination" for the the ORM/apps. "Country Name" for the source country. "Country Name" will be the exact spelling you use for said country in the Destination/Source country list.


    Please see the information below about the fields:

    a- If a field starts with "remitter.registered" then this is for the remitter profile with registration type "Registered". For Edit and Create remitter page.

    b- If a field starts with "remitter.basicregistered" then this is for the remitter profile with registration type "Basic registered". For Edit and Create remitter page.

    c- If a field starts with "benef" then this is for the beneficiary profile (create and edit page).

    d- If a field starts with "trans_new" then it is for the transaction creation page.

    e- If a field starts with "trans_payout" then it is for the transaction payout screen (when the bank pays out the transaction).

    If there are any further questions please do not hesitate to get in touch.

    This is an integration to export transactions for Mobile Transfer mainly but Cash Collection is also supported (transaction is created as cash collection but it will still be sent to Panamax to the beneficiary’s mobile number and it is assumed the beneficiary will be notified by mobile and then come and collect cash). It has its own cron job and its own classes. 

    Deployment Steps 

    1. In config_3rdparty.json copy the variable CONFIG_PANAMAX from the general  
    2. In the custom CONFIG_PANAMAX fill the fields as follows: 
      "CONFIG_PANAMAX": { 

        "enabled": true,       

        "debug": TRUE,    // true if you need to debug requests and responses     

        "processing_bank_prefix": "Panamax-",     

        "base_url": "",     

        "from_user_identifier": "[Client Phone Number]",     

        "export_transactions_cron_frequency": "*/5 * * * *",     

        "mpin": "[Client Pin]",       

        "max_export_attempts": 3,       

        "api_credentials": {    // Given by the api     

            "username": "",       

            "password": "",     


        "user_credentials": {    // Given by the client 

            "username": "",     

            "password": "",       



    1. In the config/config_state_machine.json file add new entry in `BANKS_TO_HQOK` with the same value as for `processing_bank_prefix` from the previous point.  
    2. A processing bank needs to be set up in the country where Panamax will do payout and it needs to begin with the specified prefix in config e.g. PANAMAX-GM. 
    3. Set up MNO/MNOs and delivery bank(s) and collection point(s) linked to the Panamax processing bank for the integration to work. There is no delivery import in this integration and there is no mention of MNOs or collection points in the Panamax documentation so it is up to the client to decide how they will setup the delivery entities. 
    4. For export transactions manually to Panamax, run this command (from the R1 system root folder): 
      bin/console integration panamax:export-transactions 


    This is a validation and export integration without amendments or cancellations to SmartKorpor in Sierra Leone, using SLE as the currency. The Utility Bill transfer type is implemented.

    Validation is realtime, triggered during transaction submission.

    The export is non-realtime, executed by a cron schedule.

    IP address whitelisting is not required.


    The client must provide the "Key", "Client ID" and "Secret" for the API.

    The client must do some basic setup on their production system (send the message below to the client)

    Dear ...,

    In order to prepare the SmartKorpor integration for deployment to production, could you please do the following on your production system and inform us once done.

    1. Login to ARM as an admin and add Sierra Leone as a destination country (ensuring the currency code is SLE, not SLL), if it's not already present in the list of destination countries.

    2. Ensure commission slabs exist for Sierra Leone.

    3. Create a new processing bank in Sierra Leone, including delivery bank.
    The abbreviated processing bank name and bank code should be "SMARTKORPOR-SL".
    You can create additional delivery banks if you require.

    4. Create Utility Companies for Sierra Leone from Settings > Delivery Entities.
    The Company Code should be "SMARTKORPOR-SL".

    Kind regards,

    Deployment Steps

    5. Check that the client has done the basic setup correctly.

    6. Add the following configuration to custom/config/config_3rdparty.json, following the instructions in the comments as necessary. You can ignore any additional configuration option you may find, such as master_api_key or agency_code.

        "enabled": true,
        "processing_bank_prefix": "SMARTKORPOR-",
        "processing_bank_abbrev_name": "SMARTKORPOR-SL",
        "rest_client": {
            "api_environment": "test", //test or live
            "rest_uri_live": "",
            "rest_uri_test": "",
            "key": "", //USE CLIENT PROVIDED VALUE HERE
            "client_id": "", //USE CLIENT PROVIDED VALUE HERE
            "client_secret": "", //USE CLIENT PROVIDED VALUE HERE
        "allowed_trans_types": [
            "Utility Bill",
        "export_cron_frequency": "*/5 * * * *",
        "error_notification_from_email": "",
        "error_notification_to_email": ""

    7. We need to enable the UtilityBillCompanyRouter if it's not already enabled. Check by running "vim runtimeconfig/config_routing.php". It should be under ROUTING_CONFIG->chain and not commented out.

    If it is commented out, run "vim custom/config/config_routing.json" to edit the routing, and ensure it is added as follows.


    8. In custom/config/config_state_machine.json we want to add "SMARTKORPOR-" to "BANKS_TO_HQOK" listed under the "modify_state_machine" config block, resulting in something like:

            "state_machine": { ... },
            "transaction_groups": { ... },
            "modify_state_machine": {
                    // uncomment the following line to create rules based on the prefix

    9. Ensure Settings > System Configuration Settings > CONFIG_FORMS_BASE > default > "trans_new.benef_utilitybillaccountno.display" has a value of true, or "trans_new.benef_utilitybillinvoice.display" has a value of true.

    10. In custom/config/config_notification.json add "remitone\\integration\\SmartKorpor\\SmartKorporValidateTransactionSubscriber" to the NEW_TRANSACTION event under realtime_subscriptions.

            "realtime_subscriptions": {
                "NEW_TRANSACTION": [
                    // ...
                // ...
            // ...
        // ...


    11. Run 'php bin/console app:update-system' or 'php bin/console scripts/config-update' from the terminal to load all the config changes

    12. The scheduled cron job to export s should be added automatically by Crunz, and can be manually executed from the terminal by "php bin/integration smartkorpor:export"

    If the cron job is not added (verify by executing 'crontab -l' from the terminal), add the cron job manually by running 'crontab -e' and adding the following to the bottom of the crontab:

    Note: "/THE-HOME-PATH/" refers to the full path to the project folder, eg /home/{username}/{project-folder .. mtstest, mtms, etc}/, so replace as appropriate

    */5 * * * * cd /THE-HOME-PATH/crons; /usr/bin/flock -n /THE-HOME-PATH/custom/tmp/smart_korpor_export.lock /usr/bin/php ./smart_korpor_export.php >/dev/null 2>&1

    The cron job runs every five minutes. A log file will automatically be generated at logs/smart_korpor.log

    13. Verify that the logs are being written, and if not, cd into the logs directory and run "ls -la" to check that the owner of smart_korpor.log is the logged in user, the group is apache, and read-write permissions are set.

    If corrections are needed, cd into the scripts directory and run "sh". If the permissions on the log file aren't corrected automatically, you may try the chmod command for updating the read-write permission, the chown command to change the owner to the logged in user, and the chgrp command to change the group to apache

    14. Since sometimes a utility bill invoice number is needed, and sometimes a utility bill account number is needed, and sometimes both, we need to update CONFIG_FORMS_BASE > default to include the following values:

    "trans_new.benef_utilitybillaccountno.display": true,
    "trans_new.benef_utilitybillaccountno.required": false, 
    "trans_new.benef_utilitybillinvoice.display": true,
    "trans_new.benef_utilitybillinvoice.required": false,

    15. Payonlime (the client we did the integration for in the first instance) have an existing text override on the account number field, so run "vim edit custom/libs/texts/lang.en.overrides" from the terminal and edit the override value in the return array to be 'label.entity.transaction.beneficiary_utilitybillaccountno' => 'Meter/Account No.',

    Clean Up Duplicate Remitters

    Script Location:
    1. ./scripts/clean_up_duplicate_remitters.php

    Log file Locations:
    1. ./logs/duplicateRemittersData-**.csv
    2. ./logs/duplicateRemittersLog-**.txt

    Background Information:
    1. The duplicate search method uses the already existing fuzzy search method that has been implemented on the system.
    2. The configuration to add fields to match with is called REMITTER_DUPLICATE_SEARCH, this is in the file.

    How to use script:
    1. Please ask the clients what fields they want to be included in the REMITTER_DUPLICATE_SEARCH['match_terms'] configuration setting and add an appropriate score.
    2. run the script as follows "php clean_up_duplicate_remitters.php"
    3. Answer the questions, don't add any quotation marks for the first question.
    4. Wait for the script to end and look for the logs listed above in the logs folder.

    MTMS Changes:
    1. Remitters that have been marked as a duplicate will have the remitter that has been chosen as the original listed on their profile
    2. All duplicate remitters will be set as blocked after the script has been completed.

    Orange Payment Gateway Integration Setup 

    This is an integration to make a payment in orm system. 

    It has its own cron job and its own classes. 

    1. In config_3rdparty.json copy the variable ORANGE_PAYMENT_CONFIG  from the general
    2. In the custom ORANGE_PAYMENT_CONFIG fill the fields as follows: 


            "enabled": true, 

            "logging": false, 

            "debug": TRUE,    // true if you need to debug requests and responses 

            "merchant_key": "", 

            "api_key": "", 

            "base_uri": "", 

            "logging_file": "orange_payment_logs.log", 

            "submitUrl": "{domain}/orm/orangePayment/submit", 

            "redirect_uri": "{domain}/orm/orangePayment/redirectBack", 

            "cancel_uri": "{domain}/orm/orangePayment/redirectCancel", 

            "notify_uri": "{domain}/orm/orangePayment/paymentNotification", 

            "check_payment_status_cron_frequency": "*/5 * * * *", 


    1. In config_orm.json copy the variable orangePayment from the general
    2. In the custom orangePayment fill the fields as follows:

    "orangePayment": { 

            "enabled": false, 

            "id": "xx", 


    1. For check payment transaction status, run this command
      ` orange:check-transaction-status`

    Dear RemitONE customer, let us know how we can help support you with your platform! Best wishes, Reza.

    Most popular articles 
    Newest articles