The RAM is full of useful information and features for you to explore – feel free to browse it and discover new items. The following is meant as a brief guide and introduction to the basic areas.
Upon receiving login details from the Trust Payments Malta Operations Team, you may access RAM Tool from the following link: https://www.omnipaygroup.com/ramtool
Enter your username and password.
For security reasons you are requested to change the Password. You can do this by going to Customer Service > Change Password to change your password
The Password set should include the following minimum password requirements:
- Have at least a single numeric character
- Have at least a single alphabetic character
- Password Minimum Length: 8
- Password History checks a minimum of the last 6 passwords
- Max Password Failed must not be more than 5
- Password Reset is enforced
- Password is case sensitive
Merchant identifier
Every merchant has 2 Merchant Identifiers:
- An internal merchant number (also known as a MID).
- An external merchant
OmniPay uses the MID to identify the Merchant within its own systems. The MID is up to 8 digits long. The institution identifies the Merchant by its external merchant number. This is typically the Merchant number that would be used within the institution’s own processing systems. The external Merchant number can be up to 20 digits long.
Where a RAM page requires you to enter a Merchant number, generally both the internal Merchant number and the external Merchant number are supported. If you enter an 8-digit number, RAM assumes that the number is an internal Merchant number. Otherwise, RAM assumes that the number is an external Merchant number.
Switching between Merchant numbers
If you have multiple MIDs, such as MOTO and ecommerce MIDs or multiple shops, you can switch between them by following these steps:
- Press on the drop down MID menu
- Click on the rounded arrows
- Select the other MID
Posting dates
Most items that are visible in RAM (for example, presentments, chargebacks, merchant notes) are assigned a posting date. The posting date is the internal OmniPay processing date on which OmniPay processed the transaction.
The posting date is not necessarily the same as the calendar date. For example, transactions that are processed by OmniPay during the night from March 5th to the morning of March 6th (OmniPay local time), all transactions will have a posting date of March 6th.
In addition, summary totals, such as the total value of all presentments submitted for an institution, are calculated based on the OmniPay posting date. Also, date-based searches, for example a search for all processed batches within a given date range, are conducted based on the OmniPay posting date.
Specifying date ranges in searches
When doing searches, the “Start Date” and “End Date” are mandatory fields that are used to restrict the search performed by RAM. The “Start Date” must be earlier than the “End Date”.
The dates should be entered in the format DD/MM/YYYY. A date control icon is present for all date text boxes in the system allowing for quick and simple selection of dates.
To avoid overburdening the server, some pages restrict the number of days that can be spanned by a single query, that is, the number of days between the “Start Date” and “End Date”. If the page recalculates the “Start Date” entered by a user to bring it in line with system restrictions, this date change is highlighted in red.
About account types
Transactions are credited and debited to various accounts within the OmniPay accounting system. Every account is maintained in a particular account currency (for example, USD, GBP, EUR and so on). Any transactions posted to the account that are not in the account currency are converted using the appropriate foreign exchange rates (such as the card scheme rates or the OmniPay rates). Various RAM pages require that you select an account on which to perform an operation (for example, to select an account in which to search for transactions).
- A PAR (Payment Account Retail) – Is the account where merchant batches are posted and payments generated.
- Acquirer Dispute Account – The account to which incoming chargebacks are posted and from which the chargebacks are debited to another of the merchant’s accounts, written off or re-presented.
Capture methods
The OmniPay accounting system assigns a capture method to every presentment transaction. The capture method is an internal accounting system code that describes how the transaction data (specifically the card number / PAN) is captured. The capture method is essentially a code that combines the meaning of various card scheme fields such as:
| Capture Method | Description |
| Recurring | Recurring transaction |
| SET/3D-SET authenticated | For Visa, this capture method indicates a Verified by Visa electronic commerce transaction. The capture method corresponds to Visa ECI 05. For MasterCard, this capture method indicates a UCAF (Universal Card Authentication Field) electronic commerce transaction with the UCAF data populated. The capture method corresponds to a MasterCard UCAF Collection Indicator value of 2 (the UCAF Collection Indicator is in position 3 of the Electronic Commerce Security Level Indicator field in the MasterCard clearing message). |
| SET/3D-SET non-authenticated | For Visa, this capture method indicates an electronic commerce transaction with a merchant which supports Verified by Visa, where the merchant attempted to authenticate the cardholder using Verified by Visa. The capture method corresponds to Visa ECI 06. For MasterCard, this capture method indicates an electronic commerce transaction where the merchant supports UCAF, but the UCAF data was not provided by the cardholder/issuer. The capture method corresponds to a MasterCard UCAF Collection Indicator value of 1 (the UCAF Collection Indicator is in position 3 of the Electronic Commerce Security Level Indicator field in the MasterCard clearing message). |
| eCommerce, non-secure | An electronic commerce transaction where the card details are transported to the merchant in the clear. For Visa transactions, the capture method corresponds to Visa ECI 08 For MasterCard transactions, the capture method corresponds to a MasterCard Security Protocol value of 9 (the Security Protocol is in position 1 of the Electronic Commerce Security Level Indicator field in the MasterCard clearing message). |
| eCommerce, Channel Encrypt | An electronic commerce transaction where the card details are transported to the merchant in encrypted form. This is the capture method assigned to normal SSL-based electronic commerce transactions. For Visa transactions, the capture method corresponds to Visa ECI 07. For MasterCard transactions, the “eCommerce, Channel Encrypt” capture method corresponds to a MasterCard Security Protocol value of 2 (meaning “channel encryption”). The MasterCard Security Protocol field is position 1 of the 3 position Electronic Commerce Security Level Indicator field in the MasterCard clearing message. For MasterCard transactions, the “ecommerce, Channel Encrypt” capture method may then be followed by the value of the UCAF Collection Indicator as received in the incoming transaction. The UCAF Collection Indicator is position 3 of the 3 position Electronic Commerce Security Level Indicator field in the MasterCard clearing message and is shown in round brackets. In summary, the following Capture Method texts are shown for MasterCard electronic commerce transactions:
|