Page tree
Skip to end of metadata
Go to start of metadata

Basic Information on the PMI

The PAYONE Merchant Interface (PMI) is the web-based user interface for the PAYONE platform, and provides functions for the configuration of the Merchant Account as well as administration options for processed payment transactions.
The PMI is operated in a high security computing centre as Software-as-a-Service (SaaS), which means the costs of the installation, maintenance and release-change are omitted. The PMI is developed on a continuous basis so that new features and functions can be used both automatically and immediately following their publication. It is available in German and English.

Service components

The basis for the use of the PAYONE platform is a Merchant Account in the form of a client account of the contractual partner. 

Merchant ID:
In the course of the set-up process, every merchant is assigned a unique identification number at PAYONE. This is known as the Merchant ID. Among others, this serves as a reference in the case of service enquiries in order to identify the merchant and should be stated by you every time you make contact with PAYONE. After the login has been completed, the Merchant ID is shown throughout in the top right above the logout button.

Security

A wide range of customer data, payment data and merchant information are accessible via the PMI. Numerous configurations are also saved which are essential for the smooth functioning of the merchant's E-commerce platform.

For data protection reasons and for your security, access information should be kept in a safe place and should not be forwarded to third parties. The PMI should always be exited via the logout button in the top right. 

For employees of the merchant as well as service providers who make configurations on behalf of the merchant, the PMI provides an access authorisation system with which individual access can be created by the main user of the PMI. At the same time, it can also be determined as to whether employees should be given read or write permissions for certain areas. With the appropriate administration rights, any number of accesses can be set-up and administered by the main PMI user in the PMI. For security reasons it is urgently recommended to assign the accesses on an individually specific basis only, and to assign read and write permissions as per the requirements.

Customer Account Administration

One of the basic areas of the PMI is the Customer account administration, where all of the payment processes completed via the PAYONE platform are displayed centrally. The debtor overview offers numerous opportunities for the administration of payment processes and debtors:

  • Search for debtors on the basis of differing parameters
  • Display of debtor and process accounts
  • Administration of debtors' master data and payment data
  • Display and administration of contracts and subscriptions
  • Search and display of dunning runs and reminders
  • Search and download of invoices and credit entries
  • Completion of credit entries with individual credit entry items
  • De-recognition of receivables

In the PMI it is possible to initiate a range of processes appertaining to a debtor or a process manually. The options which are displayed depend on the options which were ordered at BS PAYONE.

The debtors-overview is located in the main navigation menu.

A new dialogue box opens (pop up), in which the purchasers and transaction processes can be searched for within a portal. If a pop-up blocker is used, this window has to be opened manually using the start customer account administration button.

Payment Process and Debtor Search

The Customer account administration contains the master data for all of the purchasers of a merchant for which a receivable was created in the PAYONE platform, for instance, the name and address, email address, bank account details, closed subscriptions, etc.
The PAYONE platform runs a system-wide and successive PAYONE process number which is also referred to as the transaction-ID (TXID).

The PAYONE platform also runs an account for every purchaser which is identified by the PAYONE debtor number (user-ID). All of a purchaser's transactions are listed there. The purchaser is identified with the aforementioned PAYONE debtor or merchant customer number (customer-id). This customer number can be created by your shop system and transferred to PAYONE by interface. It serves the clear identification of the purchaser in your shop system.

Before starting the search it is necessary to select the Live or the Test mode, this is done using the radio button in the top right. The PAYONE Payment Platform can be used in two different modes: in the test mode and in the live mode. Both modes are controlled via special parameter transfers in order to be active. The platform (hardware and software) is the same in both modes. The key difference between the test mode and the live mode is that the transfer of data to external systems (e.g. banks, credit card institutes, credit agencies) only takes place in the live mode. In the test mode, all enquiries are simulated within the PAYONE payment platform or transferred to the appropriate external system in the test mode if it specifically supports a test mode. With this approach, it is possible for test scenarios to be completed with defined test data.

The add filter condition function enables a combined search via up to three search criteria (for example, first name, surname and company). 
The search result is limited to 1,000 results. If the selected search criteria encompass over 1,000 results, an error message will appear with the request to limit the search.

The interface enables the following search criteria:

  • Category: a selection of a maximum of three combinable search criteria
  • Input: input the search criteria
  • From: time frame of search (start), on day-basis
  • To: time frame of search (end), on day-basis
  • Search: the search is initialised

The search result can be displayed in sorted form on the column level (descending/ascending). In this view, the columns are:

ParameterShort Explanation
Date the time of the order (day and time of the entry of the order in the PAYONE platform)
Surname, first name the name of the purchaser
Process number unique number, as assigned by PAYONE (TX-ID)
Method of payment the payment method for the order (initial)
Status

 the status of the transaction

ParameterShort Explanation
OK the payment was successfully completed and is concluded.
Open the receipt of payment is outstanding for standard reasons (e.g. with credit transfer).
Pre-authorised the sum for payment has been reserved and not yet collected, no financial transaction has yet taken place (e.g. with credit card payments).
Empty the transaction has not been successfully concluded by the purchaser, no financial transaction has taken place. As a rule, these relate to aborted purchase transactions during the checkout process in the merchant's system or after an onward transfer (e.g. by PayPal).
Error it did not prove possible to end the transaction. Information on the reason for the error can be found in the "Details on the payment process".
in processing this status describes a booking process which is processed subsequent to being transferred to the PAYONE platform, and assumes a different status subsequent to its entry in the system. It therefore constitutes a short-term status.
Dunning status the current status in which the purchaser finds themselves.
Receivable the sum of the authorised or pre-authorised receivable. The sum before the brackets designates the current receivable, the sum in the brackets, the pre-authorised receivable.
Payment the received payment
Balance the balance of the receivable, meaning either a receivable that has been settled or a receivable that has been overpaid or underpaid.

Click on name, process number or [details], in order to access the details on the payment process view.

The detailed view of a search result occurs in two parts:

  • The master data of the customer is located on the left hand side. The buttons which are situated below open up views in which all of the processes of the selected customer are listed and can be edited on a superordinate basis.
  • On the right hand side you can find information regarding the currently selected payment process. You can carry out changes relating to this process here. These changes do not have any impact on the other payment processes of this customer.

In the following sections, the options which are available here are explained in detail. The options are context-based, which means the same options are not available with all of the customers and processes. If, for example, the process is assigned to a payment portal of the access type, special settings options for time-based settlement models are provided here.

Edit Master Data

You can view and amend the master data regarding your debtors. The most recently used invoice address and the data from the last credit card payment and bank account details are saved; neither an archiving nor versioning of the overwritten data takes place.
The master data and payment data of a debtor can be updated in different ways. In the PMI it is possible to edit or supplement the data on a manual basis Alternatively to the manual editing of the data, it is also possible to update purchaser information via an interface command (request via the API server). Since only the most recently used data are saved, in the event of a new order by the debtor with divergent information, the information available in the PMI is updated.. It is not possible to delete a debtor. To open the view with appropriate input fields in the form format, click on the edit button. The first tab contains the master data; the second tab contains the payment data.


Here, you are able to view, amend or delete the bank details and credit card details pertaining to a purchaser. The changes made here are carried out for all of the purchases of this customer on a process-spanning basis. 
For bank accounts, the account holder, account number, bank sort code, branch number, check digit (if available) or the IBAN and BIC and the country are saved. 
For credit card payments, the card holder, card type, credit card number and expiry data are all saved. Credit card numbers are only shown with the last 4 digits. This is specified by law on the grounds of PCI DSS conformity.

Integrated Blacklist

With the help of the Risk Management module specific master data can be set on blacklist to block payment transactions.
Therefore the values of

  • e-mail-address
  • IBAN (International Bank Account Number)
  • credit card number

can be set on or removed from the blacklist directly within the debtor administration. These options are only available if Risk Management module has been ordered.
In this example the e-mail-address has been put already on blacklist and can now be removed from blacklist:

While adding an entry to the blacklist you may optionally specify the expiration date of the blacklist entry. If no expiration date is given the entry is unlimited in time. 

For privacy reasons, the IBAN, account number and credit card number are not displayed completely but "masked". However, the full values are always used for the blacklist. 
If values (e-mail address, IBAN, credit card number) are put on blacklist, they do apply to all purchasers with the same value – not only for this purchaser, but for all payment attempts of your merchant account. If, for example, several purchasers use the same IBAN, all these purchasers are blocked for direct debits - as well as new purchasers using the same blacklisted IBAN.

The Contracts of a Purchaser

With the help of the Subscription Handling module, the PAYONE platform administrates recurring payments and subscriptions (contracts). In this context, via the PMI, contract templates with configurable periods and prices are defined.
The key features of the Subscription Handling module include A detailed description of the functional scope of the Subscription Handling module is available upon request.:

  • The automated administration of recurring payments
  • Differing settlement intervals (weeks, months)
  • Periods and prices are individually configurable
  • Integrated cancellation management (e.g. cancellation in the event of non-payment)

In the master data view pertaining to a debtor, click on the contracts button in order to display all the existing subscriptions.

The information displayed here consists of:

ParameterShort Explanation
Contract ID this unique ID number is generated automatically when concluding the contract
Product ID the designation of the offer that you can freely select
Method of payment the method of payment which was used for the process (usually a credit card, invoice or direct debit)
Sum the sum payable as a gross value
Subscription value the purchase value of the subscription
Start the start of the period of the subscription
End the end of the period of the subscription
Statusthe general status of the subscription: "active", "expired", "cancelled", "blocked"
Subscription statusthe status of the period of the subscription:  "active", "expired", "cancelled", "blocked". A subscription can have initial and follow-up periods. The subscription status refers to the status of these periods. Generally, both of the statuses are identical.

In the second tab, Edit contract, you can view, manage or cancel the purchaser's contracted subscriptions.

Customer Dunning Processes

The Receivables Management module displays the dunning process regarding a customer, and works closely together with the Payment module. It is responsible for the commercial dunning, and on request, the handing over of cases to external debt collection agencies in order to request overdue payments.
In the event of a chargeback or an invoice which is not settled on time, the PAYONE platform initiates the dunning process fully automatically upon request via the Receivables Management module A detailed description of the functional scope of the Receivables Management module is available upon request..
The dunning process can be configured individually and has the following functions:

  • Initialisation of the commercial dunning process after due date or chargeback
  • Automated commercial dunning process via email and/or post with up to 4 variable dunning levels
  • Dunning levels, texts and corporate design of the dunning notices in different languages are individually configurable via the PAYONE Merchant Service
  • Management of dunning periods, tolerance limits, dunning blocks as well as proposed dunning and debt collection lists

Click on the dunning button in the master data area (left) to access an overview of all the dunning processes which have so far been carried out for this customer data set. This is where you can find details on the individual dunning levels and documents (payment reminders and dunning) which have been so far sent to the purchaser.
The Dunning button in the right hand payment process area opens an overview of the dunning processes which belong to this individual process.

Under the customer dunning runs tab it is possible to filter entries according to the date. The Active only check-box filters the search results so that it is only the current dunning runs which are displayed. The search result provides the following information:

ParameterShort Explanation
PAYONE process number a unique number which is assigned by PAYONE (TX-ID)
Document the invoice number for the invoice on which the process is based (with the Invoice Issuing module ordered)
Transaction date this field is not filled in for technical reasons
Dunning level the dunning status (dunning level or debt collection)
Next dunning notice the date on when the next dunning level is triggered
Receivable the open sum of the receivable (gross value)
Fee the dunning fee as predefined by the merchant
Balance the overall open receivable

You can configure dunning notices on the payment process in the second tab. Here, you are able to manually skip the dunning levels for individual customers or carry them out again. The send dunning notice/forward case to debt collection initialises the sending of documents and/or the transfer of data to the collection agency. If this box is not activated when clicking on set dunning level, then the setting is only changed at the internal system level, and no external processes are initiated. It is also possible to amend the entry into the next dunning level individually.

Clicking on the [email] link at the end of the line takes you to a copy of the email and/or of the dunning notice which was sent to the purchaser.

 The debt collection information on the payment process tab does not contain any data for technical reasons.

Display of the debtor account

The PAYONE platform manages an individual process account for every payment process. The sum of all the process accounts of a purchaser/debtors results in the balance of this debtor. All of the receivables and payments are entered on the debit or credit side of a process account. In this way, every business transaction is reflected in an entry and is visible in the process account.

Process account:

ParameterShort Explanation
Date the time of the process
PAYONE process number the unique number which is assigned by PAYONE (TX-ID)
Process the type of the process (receivable, credit entry, chargeback, etc.)
Type of receivable the type of receivable (chargeback fee, penalty interest, delivery costs, receivable, credit entry, returns)
Debit (positive/negative) receivable
Credit (positive/negative) payment

Debtor account:

ParameterShort Explanation
Date the time of the order
PAYONE process number unique number which is assigned by PAYONE
Process the type of the process (receivable, credit entry, chargeback, etc.)
Type of receivable the type of receivable (chargeback fee, penalty interest, delivery costs, receivable, credit entry, returns)
Debit (positive/negative) receivable
Credit (positive/negative) payment

Display of all the documents on the purchaser

Here, all of the documents which have been sent out for the purchaser through the PAYONE platform (with the Invoice Issuing module ordered) are available to download as a PDF file. 

Documents on the payment process:

Audit-Log of a Debtor

All of the relevant data changes and actions as well as the logged in user of the PMI who triggered these actions are saved in the Audit-Log. All of the details can therefore be seamlessly traced.

Example of an Audit-Log

The view is not opened in the dialogue box (pop-up), but in the original window.

ParameterShort Explanation
User name the user who compiled the comment
Date the date that the comment was saved
Type of event the event on which the comment was compiled
Debtor ID the Debtor ID
Process number the process number
Comment a comment


You can filter the Audit-Logs according to up to three combinable search criteria. The search result which is filtered in this way can then be exported as a CSV file by clicking on [csv-export].

Editing a payment process

In the right hand area of the data, you obtain the initial information concerning a specific transaction which is identified due to the unique PAYONE process number. The values which are displayed offer an overview of the current status of your customer's entry, and also include a possible error reason as to why the transaction was unsuccessful. The details on the rejection are clear from the "error reason" value.

Creating a credit entry

With a credit entry, a sum which has been previously collected or received is reimbursed. On this basis, the maximum sum which can be reimbursed is that which was either collected or received. It is also possible to carry out a purely debtor-based credit entry in which no settlement, meaning no flow of funds, takes place.

ParameterShort Explanation
Description the article text which is to be shown on the invoice/credit entry voucher.
Number the quantity of the credited article
VAT (%) the rate of VAT
Price the gross price
Add position the type of receivable (chargeback fee, penalty interest, delivery costs, receivable, credit entry, returns)
Type of credit entry (optional) credit entry, return of goods, chargeback fees (de-recognition), delivery costs (de-recognition), reminder fees (de-recognition), penalty interest (de-recognition)
Total sum the sum of the credit entry (partial credit entry possible)
Maximum sum of the credit entry the maximum sum that can be paid

By clicking on Continue the credit entry is confirmed and carried out.

To create a receipt for the purchaser it is necessary for the Invoice Issuing module to be ordered. If this is not the case, the Items (optional) fields do not have any effect and can be ignored.

De-recognition of an open receivable

De-recognising an open receivable means completely de-recognising a receivable (for example: the purchaser has withdrawn from the order). In this case, no flow of funds takes place, but the balance is settled. In accounting terms, this constitutes a credit entry for a receivable, which means the name of the appropriate tab is credit entry.

ParameterShort Explanation
Old balance the current balance of the transaction
Sum of the credit note the sum which is credited (no flow of funds)
Amount disbursed the sum which is to be paid to the purchaser (movement of funds takes place)
New balance the balance that would exist after the de-recognition.
Comment a comment regarding the de-recognition (is not displayed to the purchaser). If a note is added at this point, it can be viewed in the Audit Log overview.


Transfer

It is possible for account-based payment types to be transferred with the transfer button (open invoice, direct debit, advance payment). If a purchaser pays a receivable by direct debit which has already been settled in full, for example, then this overpayment can be transferred to another receivable which is still open.

A mix of different payment types is not possible. An overpaid credit card or PayPal entry cannot therefore be transferred to an open receivable which has taken place via an invoice.

Content


  • No labels