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

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:

1. Search for debtors on the basis of differing parameters
2. Display of debtor and process accounts
3. Administration of debtors' master data and payment data
4. Display and administration of contracts and subscriptions
5. Search and display of dunning runs and reminders
6. Search and download of invoices and credit entrie
7. Completion of credit entries with individual credit entry items
8. De-recognition of receivables

---end

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.

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.

For the direct debit payment method, you can download the mandates here.

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

• 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.

Add to Blacklist

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)

---end

Contracts for the Customer

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

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.

Dunning Procedures for the Customer

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:

Dunning Letters for the Payment Event

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.

Dept Collection Information on the Payment

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

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.

Event Account

Customer Account

---end

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	Accordingly, the documents assigned to the payment transaction can be found here.

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.

---end

Example of an Audit-Log

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.

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.

---end

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.

---end

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.

---end