Monitoring and performing payments

Overview

Dashboard interface allows you to monitor payment processing and perform payments in the following sections:

  • Payments—a section for monitoring information on all payment types and performing certain operations, which includes initiating capture and cancel operations within a two-step purchase, refunding purchases of any type, and issuing payouts.
  • Payment links—a section for performing payment link purchases.
  • Manual payments—a section for performing single MO/TO payments and payouts as well as sending batch requests to capture held funds or cancel authorisation holds and to issue mass refunds and payouts.
  • Subscriptions—a section for managing subscriptions.
  • Remittances—a section for making B2B payments to corporate accounts (learn more).

In both Payments and Manual payments sections, payment processing can be monitored in the corresponding consolidated register, with the possibility to filter data. In each register, users can also view detailed payment information about individual payments. Detailed payment information is shown in separate tabs, which allows users to switch between the register and the tabs more efficiently.

These sections contain registers that allow users to view detailed information about individual payments in the separate payment information tabs. Access to sections and their specific features is granted through a relevant set of permissions (learn more).

Figure: Payments list in the Payments section



When performing payment operations in the Dashboard interface, you can initiate a:

  • single operation when parameters are specified directly in the Dashboard interface and one request is sent to execute one operation.
  • mass operation when parameters are uploaded in a file of the specified format following which a batch request is sent to execute multiple operations.

Access to sections Payments, Payment links, and Manual Payments and their specific features is granted through a relevant set of permissions. Therefore, if any of the features described below is not available to a certain user, you need to verify whether the user account in question has the appropriate set of permissions. Moreover, in order to perform MO/TO payments and payouts, users are required to have two-factor authentication enabled when accessing Dashboard. Payouts may also need to enter verification codes sent by text (SMS) to confirm executing the operations. To learn more, see How to access.

The guidelines on how to monitor payment processing, initiate payments, and work with batch requests are provided below.

Monitoring payment processing

Dashboard users can monitor information about amounts, statuses, and other attributes of the processed payments. For this purpose, you can use the Payments section with the comprehensive information about all payment types and the sections with the information about specific payment types. Each of these sections contains a list with the standard filtering tools (learn more). In addition, sections Payments, Manual payments, and Subscriptions have payment information tabs that specify details of individual payments and all operations initiated within them (to open the payment information tab, click the row of the payment you need in the list).

Dashboard users can monitor information about payment processing in the Payments section with the comprehensive information about all payment types and the Manual payments and Subscriptions sections with the information about specific payment types. Each of these sections contains a list of payments and payment information tabs that specify details of individual payments.

Figure: Payment information tab

To monitor information about specific payments:

  1. Select the section you need: Payments, Payment links, Manual payments, or Subscriptions.
  2. Find rows with the information about specific payments in the list. Use filters, if necessary.
  3. Verify the information you need, either in the list or in the payment information tabs, if they are available.

However, when you work with lists, keep in mind the following:

  • Information in lists and payment information tabs is shown with a time lag which can take up to several minutes. While automatic data refresh is not supported, you can refresh data in the payments list with the use of the button located in the left corner above the list.
  • The number and the order of columns in the lists can be customised, which means that with the appropriate set of permissions the lists can be arranged according to individual needs.
  • Key attributes of payments, which include identifier, type, status, amount, and currency, are by default shown in the first columns of the lists. They are used for filtering data with predefined filters on the filtering panel. It depends on the list which attributes and filters are available for filtering data.
  • The Amount field shows the payment's base amount to which the status of the said payment currently applies.

    For example, if a partial refund for 20 EUR was issued for the payment of 100 EUR, then the status partially refunded applies to the amount of 100 EUR, while the refund amount and the remaining amount are shown in the Refunded and Available for refund fields.

    Another example is a regular COF purchase. For this payment type, the Amount field shows the actual amount of the received funds.

If you have any questions about working with lists, contact your account manager.

Performing purchases

Overview

Dashboard allows users to:

  • Create, send, and deactivate payment links in order to process one-time purchases and register regular COF purchases (if necessary). General description of the payment link purchase workflow and possible statuses can be found in the corresponding article.
  • Take MO/TO (Mail Order / Telephone Order) payments using a payment form when the customer provides payment card details over the phone, by email, or other means of communication. MO/TO payments are processed as one-time purchases according to the workflow. Certain restrictions may apply.
  • Manage authorisation holds as part of executing two-step purchases. Held funds can be captured or released with the use of individual and batch requests. General description of the two-step purchase workflow and possible statuses can be found in the corresponding article.

Requirements

To perform purchases by using Dashboard, the following requirements must be met:

  • Two-factor authentication is required for accessing Dashboard in order to take MO/TO payments.
  • The user account must be granted the appropriate permissions. Each action, including capturing held funds and releasing authorisation holds, requires a specific permission.
  • Required actions are supported for the selected project and the payment method.

If any issues regarding access rights occur, they can be solved with the merchant's specialists.

MO/TO payments

To take a MO/TO payment:

  1. Go to the MO/TO (vPOS terminal) tab.

    Go to Manual payments, click Request on the left of the filtering panel, and switch to the MO/TO (vPOS terminal) tab.

  2. Specify payment parameters and send the request to open the payment form by filling in the fields and clicking Pay.

    When filling in the fields, keep in mind that:

    • The payment ID must be unique for the specified project.
    • The amount is entered as a decimal number with a point to separate fractional part (for example, 314.15).
    • The Pay button is enabled when all required parameters have been specified.
  3. In the payment form specify the required data and confirm the payment by filling in the fields in the payment form that opened and click the Pay button.

    If the field Country is used, enter the country code in accordance with ISO 3166-1 alpha-2. The list of country codes can be found in Country codes).

  4. Make sure that the payment has been processed.

    You can do this by checking the status of this payment in the payments list—it should state success.

    If the payment has been declined, its status switches to decline. The decline can happen due to a variety of reasons. For example, it can be caused by providing incorrect card details, in which case you should initiate another payment with a new payment ID while making sure that the card details are specified correctly.

  1. Go to the MO/TO (vPOS terminal) tab by clicking Request in the Manual payments section.
  2. Specify payment parameters and send the request to open the payment form by clicking Pay.
  3. In the payment form specify the required data and confirm the payment by clicking Pay.

    If the field Country is used, enter the country code in accordance with ISO 3166-1 alpha-2. The list of country codes can be found in Country codes).

  4. Make sure that the payment has been processed by checking its status—it should state success.

Single capture and cancel operations

To initiate debiting of the authorised amount (cancel authorisation hold) as part of executing an individual two-step purchase:

  1. If necessary, locate the purchase that requires debiting (release) of the authorised amount.

    You can use the Search function (search by payment ID, for example) or go to the Payments section and apply necessary filters in the lists (for example, filter by operation type—auth, or by payment status—awaiting capture).

  2. Open the payment information tab for the target purchase.

    Click the corresponding row in the list of the Payments section.

  3. Send a capture (cancel) request.
    1. Click the Capture button located on the payment management panel (at the top left of the payment information tab) to initiate the debiting of the authorised amount (click the Cancel button to release the authorisation hold).
    2. In the window that opens, specify the required amount, which can be the entire authorised amount or its part.

      When changing the authorised amount, keep in mind that this capability is not universally supported (due to regional specifics or other reasons) and that certain restrictions are imposed by payment systems (to learn more, see Request for partial debit or release of authorised amount).

    3. Confirm your request by clicking Capture (Cancel).
      Note: If buttons Capture and Cancel remain inactive, it may mean that one of these operations is already being processed. If these buttons are absent, it may mean that performing such operations is not allowed for the payment.
  4. Make sure that the capture (cancel) operation has been processed.

    You can do this by checking the status of this operation in the tab with the detailed information about the target purchase. You can also check the status of this purchase in the payments list. The status of the operation (capture or cancel) should state success, while the status of the purchase should state success if the held funds were captured and cancelled—if the hold on funds was released.

  1. Open the payment information tab of the target purchase in the Payments section.
  2. Click the Capture (Cancel) button on the payment management panel to send a capture (cancel) request.
  3. In the window that opens, specify the required amount (in full or its part) and confirm the request by clicking Capture (Cancel).
  4. Make sure that the capture (cancel) operation has been processed by checking its status.

    The status of the operation (capture or cancel) should state success while the status of the purchase should state success if the held funds were captured and cancelled—if the hold was released.

If the operation request has been declined, its status switches to decline while the payment status remains awaiting capture.

Mass capture and cancel operations

To perform capture or cancel operations using a batch request:

  1. Create and prepare the file with the capture (cancel) operations data in the specified format.

    You can find the file requirements with the template and a file sample below.

    Restriction: When preparing the file, keep in mind that it must contain operations of only one type—either capture or cancel, while both the entire authorised amounts and the partial amounts can be specified as the amounts to capture (cancel). It is important to remember that changing the authorised amount is not universally supported (due to regional specifics or other reasons) and that certain restrictions are imposed by payment systems (to learn more, see Request for partial debit or release of authorised amount).
  2. Go to Mass Captures (Mass Cancels).

    Go to Manual payments, click Request on the left of the filtering panel, and switch to the Mass Captures (Mass Cancels) tab.

  3. Upload the file with the list of operations and check it for data consistency.

    Drag the file or use the Browse button to upload.

    Following the validity check, either the Send request button is enabled, or the error message is shown. In the latter case, you can view the details of the error (using the File preview toggle and then the File details button), correct the error and re-upload the file.

  4. Send the batch request by clicking Send request.
  5. Make sure the requests have been processed.

    You can monitor statuses and indicators of batch processing and statuses of individual operations.

    To monitor the state of batch processing in the list of mass requests, click Mass requests on the filtering panel in the Manual payments section, find the row of the batch you need in the list and check its status and indicator. Keep in mind that the time it takes to process operations and to update their status information can significantly vary depending on the number of operations in the batch. When the batch has been processed, its status should state Done.

    To check the status of individual operations, check the status of the payments that require performing capture or cancel operations in the payments list (they should have the status success when the authorised amount is debited or cancelled when the authorisation hold is released). You can also check the statuses of operations in the corresponding payment information tabs (they should state success or decline depending on the operation result).

  1. Create and prepare the file with the capture (cancel) operations data in the specified format.

    You can find the file requirements with the template and a file sample below.

    Restriction: The file must contain operations of only one type—either capture or cancel, while both the entire authorised amounts and the partial amounts can be specified as the amounts to capture (cancel). To learn more, see details.
  2. Go to Mass Captures (Mass Cancels) by clicking Request in the Manual payments.
  3. Upload the file with the list of operations and check it for data consistency.
  4. Send the batch request by clicking Send request.
  5. Make sure the requests have been processed by checking statuses and indicators of batch processing and statuses of individual operations.

    Statuses of the individual capture or cancel operations should state success while statuses of the relevant payments should state success when the authorised amount is debited or cancelled when the authorisation hold is released.

Managing subscriptions

Overview

Dashboard interface allows users to register regular COF purchases (subscriptions), monitor their processing, update subscription settings, and cancel debiting series of the registered COF purchases.

Regular purchase is a type of COF purchase initiated by the merchant with automatic debits on specific schedule and with the fixed charged amount. After the registration of the regular COF purchase in the payment platform, the information about it is shown in the Subscriptions list. The regular COF purchase can have the following statuses:

  • Not set is assigned to regular COF purchases that do not have all of their settings specified, hence no automatic debits are executed.
  • Active is assigned to activated regular COF purchases with automatic debits executed on schedule.
  • Active is assigned to activated regular COF purchases with debiting terms already set and automatic debits executed on specified schedule.
  • Cancelled is assigned to regular COF purchases with subsequent automatic debits cancelled.
Note:

If you have not specified the identifier of the regular COF purchase in the scheduled_payment_id parameter and set up the debiting terms when registering it, this purchase is assigned the Not set status in the subscriptions list. Along with that, the Recurring payment panel of the payment information tab displays a warning that the user needs to specify the regular COF purchase parameters to start charging the customer.

In the Subscriptions section you can access payment information tabs with details of regular COF purchases. Each tab includes several panels including the payment management panel, the Recurring payment panel with the data of all regular COF purchase debits performed so far, and the Registration payment panel with information about the regular COF purchase registration. In this tab, you can also manage subscription settings, cancel subsequent debiting executed as part of the subscription, and view change history. The buttons for performing these actions become active on the payment management panel if you have the appropriate permissions. The step-by-step instructions are provided below.

In the Subscriptions section you can access payment information tabs with details of regular COF purchases. With the appropriate permissions you can view information about all operations performed as part of the regular COF purchase, manage subscription settings, and cancel subsequent debiting executed as part of the subscription.

Figure: Payment information tab with subscription details

Registering subscriptions

The ecommpay payment platform allows you to register regular COF purchases with automatic debits in a variety of ways including when payments are processed via Payment Page (details) and Gate (details) and by migrating information about COF purchases and payment card tokens (details).

Along with that, Dashboard allows you to register regular COF purchases with the use of payment links by specifying additional information when you create them. This procedure is described above. When the customer clicks such payment link and completes the purchase, the regular COF purchase becomes activated and is assigned the Active status in the subscriptions list.

Updating subscription settings

To specify or modify the debiting terms of the regular COF purchase (subscription):

  1. Open the payment information tab of the subscription you need.

    You can use the Search function (search by payment ID, for example) or go to Subscriptions and use the registry and filters.

  2. Open the Subscription settings window and switch to editing mode.

    Click Go to Settings in payment management panel and then click Edit in the bottom right corner of the window that opens.

  3. Specify or modify target parameters of the regular COF purchase.

    Fill in the fields and click Save.

    When filling in the fields, keep in mind that:

    • If the regular COF purchase identifier was not provided at the time of registration (such payment has a Not set status in the registry), the Recurring payment ID field is required. If the identifier has been provided, this field is read only.
    • Fields to specify the debiting amount, period, and the date when the next debiting is supposed to occur are required. If at least one field is left empty, an attempt to save changes triggers an error notification.
    • The date when the next debiting is supposed to occur cannot precede the current date and cannot occur later than the expiration date of the regular COF purchase.
    • Fields Currency and Subscription end date are read only. The currency of the subscription is always the currency of the registration payment. If the last recurring date has not been specified in the regular COF purchase registration request, it is set to the expiry date of the payment instrument (for example, card) used to make this COF purchase.
    • Fields Every (for specifying the multiplicator to increase debiting period) and Description are optional.

    If you need to discard any unsaved changes to the subscription settings, click Cancel

  4. Make sure that the changes have been saved.

    You can do this by clicking Settings History on the payment management panel: the registry of changes to subscription terms should contain a record of the update. In addition, the status of the regular COF purchase in the subscriptions list should change from Not set to Active.

  1. Open the Subscription settings window in the subscription information tab and switch to editing mode by clicking Edit.
  2. Specify or modify target parameters of the regular COF purchase and click Save.

    Keep in mind that fields Recurring payment ID (if it has been specified), Currency and Last recurring date are read only.

  3. Make sure that the changes have been saved.

    Check if the Settings History registry contains a record of the update and the status of the regular COF purchase has changed from Not set to Active in the subscriptions list.

Managing debiting retry attempts

Overview

One attempt is usually enough to perform a scheduled debit executed as part of a COF purchase. However, in some cases, for example, when the customer's card account has insufficient balance, it can be useful to retry the debiting after a certain amount of time. The ecommpay payment platform has the capability to retry COF purchase debits automatically (learn more).

This capability is set up upon agreement with your account manager, and when it is supported for the project, you can manage and cancel debiting retries in the Dashboard interface.

Monitoring retry attempts

Information about debiting retries performed as part of a COF purchase is shown in subscription information tabs of Dashboard (if this capability is set up for the given project). To view this information in the subscription tab, use the Show retries button. To return to viewing the information about the initial debit operation, click Back to main operation.

Table 1. Subscription tab panels for working with debit operations and debiting retries
Panel Working with debit operations Working with debiting retries
1. Panel with the list of all actions

shows the list of debit operations and refunds for a specific regular COF purchase (each list item corresponds to an individual debit operation, shows its status and can show the status of debiting retries)

shows the list of retry attempts for a specific debit operation (each list item corresponds to an individual retry attempt, shows its status and is marked with the retry operation attribute)

2. Panel for performing a specific action.

shows the information about a specific debit operation (including an explanatory note to the status of the debiting retries)
and buttons to switch to the list of debiting retries and to cancel the retry attempts to manage this operation

shows the information about a specific retry (including the retry operation attribute) and the button to return to the list of all debit operations executed as part of a COF purchase

3. Panel with information about a specific action shows detailed information about a specific retry shows detailed information about a specific retry

To help you monitor retry attempts, the following statuses are assigned to the retries attempted as part of a scheduled debit operation:

  • retries active—the debiting retry has been scheduled in the payment platform (when the scheduled debit operation was declined by the payment system or the issuer).
  • retry in progress—the retry attempt is performed.
  • retries successful—one of the attempted retries resulted in debiting the funds from the customer to the merchant.
  • retries unsuccessful—all available retries have been declined.
  • retries cancelled—retry attempts have been cancelled (either by request from the merchant or automatically, due to modification of the COF purchase debiting terms or other reasons).

To view information about retry attempts for a specific debit operation:

  1. Open the payment information tab of the subscription you need in the Subscriptions or Payments section.

    You can use the Search function (search by payment ID, for example) or go to Subscriptions or Payments and use the registry and filters.

  2. Go to the detailed information about the specific debit operation.

    Select the item on the panel with the list of debit operations on the left of the subscription tab.

  3. Open the list of the debiting retries.

    Click Show retries on the panel for managing the debit operation.

  4. Go to the detailed information about the specific retry.

    Select the item on the panel with the list of debiting retries on the left of the subscription tab.

  5. If necessary, return to the list of all debit operations.

    Click Back to main operation on the panel for managing the debiting retry or click in the top right corner of the panel with the list of retries.

Cancelling retry attempts

To cancel retrying a specific debit operation:

  1. Open the payment information tab of the subscription you need in the Subscriptions or Payments section.

    You can use the Search function (search by payment ID, for example) or go to Subscriptions or Payments and use the registry and filters.

  2. Go to the detailed information about the specific debit operation.

    Select the item on the panel with the list of debit operations on the left of the subscription tab.

  3. Cancel debiting retries.

    Click Cancel retries on the panel for managing the debit operation and confirm cancellation.

  4. Make sure that the retries have been cancelled.

    Check the status of the retries in the row of the corresponding debit operation on the panel with the list of all debit operations: it should change from active to retries cancelled.

Cancelling the subscription

To cancel automatic debits executed as part of the regular COF purchase:

  1. Open the payment information tab of the subscription you need.

    You can use the Search function (search by payment ID, for example) or go to Subscriptions and use the registry and filters.

  2. Open the Subscription settings window and select cancelling the subscription.

    Click Go to Settings in payment management panel and then click Cancel Subscription in the top left corner of the window that opens.

  3. Open the Subscription settings window and click Cancel Subscription.
  4. Confirm cancellation in the pop-up window.
  5. Make sure that the subscription has been cancelled by checking its status.

    Click Settings History on the payment management panel: the registry of changes to subscription terms should contain a record of the update. In addition, the status of the regular COF purchase in the subscriptions list should state Cancelled.

Issuing refunds

Requirements

Dashboard interface allows users to refund all types of purchases either in full or in part, which includes refunding individual debits executed as part of the COF purchase. Issuing refunds can be done with the use of individual and batch requests, and in each case, the following requirements must be met:

  • The user account has been granted the right to issue refunds.
  • The purchase (the individual debit executed as part of the COF purchase) has been fully processed.
  • Refunds of the required type are supported for the payment method used to make the purchase.
  • The balance under which an initial payment was performed has enough funds for issuing a refund

If any issues regarding these requirements occur, they can be solved with the specialists in charge of granting access rights and working with balances.

Single refunds

In Dashboard you can issue single refunds (full and partial, for all types of purchases) both in the payments list and in the payment information tabs (for example, if you need to refund a specific operation within a COF purchase).

To refund a single purchase:

  1. If necessary, locate the purchase you need in the Payments section that needs to be refunded.

    You can use the Search function (for example, search by payment identifier) or go to the Payments section and apply necessary filters in the lists (for example, filter by payment type: purchase, recurring, invoice, or account verification).

  2. Open the window to initiate a refund by clicking the button in the corresponding row of the payments list or the Refund button in the payment information tab.

    Click the button in the corresponding row of the payments list, or open the payment information tab and click the Refund button located on the payment management panel or on the panel with the information about the specific operation of the COF purchase.

    Note: If the Refund button is disabled, it can mean that the purchase has not been fully processed yet. If this button is not shown at all, it can mean that refunding purchases is not supported for the utilised payment method (in which case refer to your ecommpay account manager for more details).
  3. Send a refund request.

    In the window that opens, specify the amount you need to refund—full available or its part (the amount available for refund is also shown in this window), then click Refund.

    Restriction: Keep in mind that clicking the Refund button initiates the refunding operation. You will not be separately asked to confirm your request.
  4. Make sure that the refund has been issued. The status of the refund operation should state success.

    You can check the status of the refund operation in the payment information tab (it should state success) or the status of the payment in the payments list (when the payment is refunded in full, the status is refunded or reversed; when only the part of the payment amount is returned, the status is partially refunded).

If the refund has been declined, the status of the operation switches to decline while the status of the payment remains unchanged. The decline can happen due to a variety of reasons. For example, it can be caused by the lack of funds, in which case you can add funds to the balance and try to issue a refund again.

Mass refunds

To issue multiple refunds using a batch request:

  1. Create and prepare the file with the refund data in the specified format.

    You can find the file requirements with the template and a file sample below.

    Note: When preparing the file, keep in mind that to refund purchases, you must specify the identifier of the payment to be refunded in the general.payment_id field while to refund an individual debiting operation performed as part of the COF purchase, you must also include the identifier of the operation to be refunded in the general.operation_id field.
  2. Go to the Mass Refunds tab.

    Go to Manual payments, click Request on the left of the filtering panel and switch to the Mass refunds tab.

  3. Upload the file with the list of refunds and check it for data consistency.

    Drag the file or use Browse button to upload.

    Following the validity check, either the Send request button is enabled or the error message is shown. In the latter case, you can view the details of the error (using the File preview toggle and then the File details button), correct the error and re-upload the file.

  4. Send the batch request by clicking Send request.
  5. Make sure the refunds have been processed.

    After the batch request has been sent and you can see the notification that it has been accepted, it is important to check that the refunds have been processed. Look up the batch status in the list of mass requests—the status should state Done (click Mass requests on the filtering panel in the Manual payments section and find the row of the batch you need in the list). You can also monitor status information of individual refunds using the column Indicator. Keep in mind that the time it takes to process refunds and to update their status information can significantly vary depending on the number of refunds in the batch.

    To check the status of individual refunds, check the status of the payments that need to be refunded in the payments list (they should have the status refunded or reversed when the payment is refunded in full and partially refunded when only the part of the payment amount is returned). You can also check the status of a refund in the corresponding payment information tab (it should state success or decline depending on the operation result).

  6. Make sure the refunds have been processed by checking statuses and indicators of batch processing and statuses of individual operations.

    Statuses of the individual operations should state success while statuses of the relevant purchases should state refunded or reversed when the purchase is refunded in full and partially refunded when only the part of the payment amount is returned.

If you have any questions about issuing refunds, contact technical support specialists.

Performing payouts

Requirements

Dashboard interface allows users to perform payouts with the use of individual and batch requests. In both cases, the following requirements must be met:

  • Two-factor authentication is enabled for the Dashboard user account in question.
  • The user account has been granted the right to perform payouts.
  • Payouts are supported for the selected payment method.
  • The balance under which payouts are performed has enough funds.
  • If additional data is required to perform a payout, it has to be provided within 22 hours.

If any issues regarding these requirements occur, they can be solved with the specialists in charge of granting access rights and working with balances.

In any payout type—either single payout or batch payout—you can issue one or more retries if the initial attempt is declined, for example because daily limit for payouts in the payment system is reached or the payment system services are unavailable. The payment platform can be set up to issue retries automatically after specific timeout, or technical support specialists can issue them manually. The number of retries is always limited. To enable retry functionality, contact your account manager at ecommpay; to set up retries number limit and delay between retries, contact technical support service (support@ecommpay.com).

Payment platform can be set up to issue retries of both single and batch payouts when the initial attempt is declined. To enable this functionality, contact your account manager; to set up—contact technical support.

Single payouts

To perform a single payout:

  1. Go to the Single payout tab.

    Go to Manual payments, click Request on the left of the filtering panel and switch to the Single payout tab.

  2. Specify payout parameters and send a payout request.

    Fill in the fields and click Send Request; if needed, enter the SMS verification code in the popup window.

    When filling in the fields, keep in mind that:

    • The amount is entered as a decimal number with a point to separate fractional part (for example, 314.15).
    • Fields for the payment method specific parameters are not available until the project, the amount, the currency, and the payment method have been specified.
    • Among the specific fields only the required ones are shown.
    • If the field is filled incorrectly, the error message "Specify payout parameters" is shown.
    • The Send Request button is enabled when all parameters have been specified correctly.
  3. If additional payment information is required, specify the parameters needed (you can also decline the payment).

    When the payout is processed, its parameters are validated, following which a notification is displayed in the Single payout tab. If the parameters satisfy all requirements, the notification states that the request has been successfully processed. If certain parameters, which are not mandatory in general but can be required in a specific situation, are absent, fields where you can enter the required additional information are shown. In this case, to proceed with the payment, specify the information needed and click Proceed; to decline the payment, click Reject Payout.

    If for any reasons (to get more accurate information, for example) you need to pause and return to performing the payout later, you can find this payout in the payouts list using the Clarification filter and clicking the corresponding row.

    Restriction: By default, additional payment information has to be provided no later than 22 hours after the clarification request was received. However, certain payment systems may require additional information specified within shorter amounts of time. Contact technical support for more information about specific payment methods.
  4. Make sure that the payout has been processed.

    Verify the status of this payout in the Payouts or Payments list—it should state success.

  1. Go to the Single payout tab in the Manual payments section.
  2. Specify payout parameters and send a payout request.
  3. If additional payment information is required, specify the parameters needed (you can also decline the payment).

    If necessary, you can pause and return to performing payouts later. These payouts can be found in the payments or payouts list by using the Clarification filter.

  4. Make sure that the payout has been processed by checking its status— it should state success.

If the payout is declined, the payment status switches to decline. It can happen due to a variety of reasons. For example, it can be caused by the lack of funds, in which case you can add funds to the balance and try to perform a payout again.

Mass payouts

General steps

To perform a series of payouts using a batch request:

  1. Create and prepare a file with the payout data in the specified format.

    You can find the file requirements with the template and a file sample below.

  2. Go to the Mass payouts tab.

    Go to Manual payments, click Request on the left of the filtering panel and switch to the Mass payouts tab.

  3. Upload the file with the list of payouts and send the batch request.

    Drag the file or use the Browse button to upload. After the file has been uploaded, make sure the Send request button is enabled. Use this button to send the batch request; if needed, enter the SMS verification code in the popup window.

    If the file is incorrect, the Send request button remains inactive and the error message is shown. In this case, view the error details (using the File preview toggle and then the File details button), correct the errors, and re-upload the file.

  4. Make sure the specified data is sufficient and the payouts have been processed.

    After the batch request has been sent and you can see the notification that it has been accepted, it is important to check that the payouts have been processed. Look up the batch status in the list of mass requests—the status should state Done. Keep in mind that the time it takes to process payouts and to update their status information can significantly vary depending on the number of payouts in the batch and the payment methods used.

    If a single payout request in the entire batch requires additional information, the batch status switches to Clarification. In this case, you can either specify the parameters needed for the target payouts, or decline them. Learn more about these options below.

    You can also monitor status information of payouts in the batch using the column Indicator in the list of mass requests.

  1. Create and prepare a file with the payout data in the specified format.

    You can find the file requirements with the template and a file sample below.

  2. Go to the Mass payouts tab in the Manual payments section.
  3. Upload the file with the list of payouts and send the batch request.
  4. If you need submit additional payment information, specify the required parameters (you can also decline processing of certain payments).

    If necessary, you can pause and return to performing the payout later, you can find this payout in the payouts list by using the Clarification filter.

  5. Make sure that the payouts have been processed by checking their statuses—they should state success.

Submitting additional information

When the payout batch request is processed, parameters of each payout have to be validated. If the parameters satisfy the requirements, no additional actions are necessary. If certain parameters, which are not mandatory in general but can be required in a specific situation, are absent, you need to submit additional information. This necessity is indicated by the status Clarification for individual payouts and the entire batch in the list of mass requests.

If submitting additional information is necessary for certain payouts in the batch, you can selectively specify the required parameters or decline these payouts. In such cases, you can work with individual payouts (which is convenient when additional information is required only for one payout in the entire batch, for example) or several payouts at the same time (when additional information is required for a series of payouts, for example) and specify the information needed in the Dashboard interface or by uploading a file.

If you need to submit additional information, it is indicated by the status Clarification for individual payouts and the entire batch in the list of mass requests. In Dashboard you can work both with individual payouts and with a series of payouts in the batch. You can also reject processing of these payouts.

To submit additional information for a single payout:

  1. Locate and open the payout information tab you need.

    To find this payout in the All requests list, use the Clarification filter and click the corresponding row.

  2. Specify the requested data and click Proceed.

You can also use the payout information tab to decline the processing of this payout by clicking Reject Payout.

To submit additional information for a series of payouts:

  1. Locate and open the batch with the target payouts whose parameters require clarification.

    To find this batch in the Mass requests list, use the Clarification filter and click the corresponding row.

  2. Switch to editing mode by clicking Manage on the left of the filtering panel.
  3. Specify the required parameters.

    You can use the Dashboard interface directly by entering data into the cells marked with or update the file you have uploaded. In the latter case, download the file using the button. Specify the required parameters in the cells marked *required* and upload the updated file using the button.

    In each of these cases, you can submit additional data for payouts that you need to be processed, not necessarily all that require it. The ones which you have decided not to specify additional information for are going to be declined after the clarification waiting time is over.

    Restriction: By default, additional payment information has to be provided no later than 22 hours after the clarification request was received. However, certain payment systems may require additional information specified within shorter amounts of time. Contact technical support for more information about specific payment methods.
  4. Save changes and send data by clicking Apply.
  1. Locate and open the required batch in the Mass requests list by using the Clarification filter.
  2. Switch to editing mode by clicking Manage on the left of the filtering panel.
  3. Specify the required parameters via Dashboard by entering data into the cells marked with or by using the button to update the file.

    In each of these cases, you can submit additional data only for payouts that you need to be processed. The rest of them will be declined after the clarification time is over.

  4. Save changes and send data by clicking Apply.

Editing mode also allows you to decline processing of individual payouts. Check the rows you need (in the first column of the table) and click Reject.

If you have any questions about performing payouts, contact technical support specialists.

Mass payments data

File upload requirements

To prepare the file, you can use the template available for download on Dashboard or here. Having downloaded the template, you can fill it in any CSV file editor, for example, Microsoft Excel. Each file used for adding criteria in bulk must meet the following requirements:

  • The data files must be uploaded in CSV format and the character encoding must be UTF-8 without BOM (Byte Order Mark string).
  • The file size cannot exceed 128 MB.
  • The first row must contain the names of parameters. The order of parameters can be random.
  • The subsequent rows must contain values of target parameters. Specifying values for optional parameters is recommended but not required.
  • All parameter values in the file must meet the requirements provided in the table below.
  • If operation parameters are specified in strings (not in table format), parameter values in each row must be separated by a semicolon (";"). In addition, the fields without values are separated by semicolons in the same way as the fields with values, and two or more ";" characters can follow one another, for example:


    If you use Microsoft Excel to create and prepare the file, make sure that strings do not include incorrect separators or extra characters. You should use a different editor, for example Notepad, to check if extra characters have been added.

Parameters for mass payments

When adding data to files, you can use the parameters presented in the table below.

Parameter Description

operation_type
string, required

Operation type. The value can be capture, cancel, refund,  and payout.
Example: refund

general.project_id
integer, required

Project identifier assigned by ecommpay at the stage of integration.
Example: 35

method
string, required

Payment method identifier. For the full list, see Payment method codes.
Example: card

general.payment_id
string, required *

Payment identifier unique within the merchant's project.
A string which contains between 1 and 255 characters and which can include any letters, digits, and symbols in UTF-8 encoding.

Example: payment_536231.
* For refund, general.payment_id must be the identifier of the purchase to be refunded

general.operation_id
string, required *

Payment operation identifier provided by ecommpay.
A string which contains between 1 and 255 characters and which can include any digits in UTF-8 encoding.

Example: 58468298003.
* To refund a specific debiting operation performed as part of the COF purchase, specify the identifier of the operation to be refunded

payment.amount
integer, required

Payment amount in minor currency units.
An integer between 1 and 10000000000000 (without a decimal separator between the integer and fractional parts).

Example: 1905 for 19.05 and 190500 for 1905

payment.currency
string, required

Payment currency code in ISO 4217 alpha-3 format.
Example: EUR

payment.description
string, optional *

Payment description.
A string, must not exceed 255 characters.

Example: Deposit 12456.
* Required for refunds

account.number
string, optional

Account number of the customer.
A string, must contain between 1 and 100 characters.

Example: 1670033323

account.bank_id
integer, optional

Bank identifier received from ecommpay. For more information about banks and their IDs, see the section on payment methods in the documentation, or contact ecommpay technical support specialists.
An integer, must be 1 or greater.

Example: 421

account.customer_name
string, optional

First name and last name of the account holder.
A string, must contain 1 character or more.

Example: John Johnson

account.branch
string, optional

Name of the customer's bank branch.
A string, must not exceed 255 characters.

Example: Bank branch

account.city
string, optional

City of the bank branch location.
A string, must not exceed 255 characters.

Example: London

account.region_id
integer, optional

Region or state identifier of the bank branch location received from ecommpay. For more information about regions and their IDs, see the section on payment methods in the documentation, or contact ecommpay technical support specialists.
An integer, must be 1 or greater.

Example: 3

card.pan
integer, optional *

Card number of the customer.
An integer, must contain 32 digits or fewer.

Example: 2333776109871312.
* Required for payouts if token is not present

card.year
integer, optional *

Expiration year of the customer's card.
An integer between 2020 and 9999.

Example: 2024.
* Required for payouts

card.month
integer, optional *

Expiration month of the customer's card.
An integer between 1 and 12.

Example: 12.
* Required for payouts

card.card_holder
string, optional  *

Name of the cardholder as specified on the card.
A string, must not exceed 255 characters.

Example: John Johnson.
* Required for payouts

token
string, optional *

Card token received from ecommpay.
Example: Z0yTL5shY8ddhpxdQyplRPJYmGV7Kv.
* Required for payouts if card.pan is not present

customer.id
string, optional *

Identifier of the customer within the merchant's project.
A string, must not exceed 255 characters.

Example: customer313.
* Required for payouts

customer.country
string, optional *

Customer country code in ISO 3166-1 alpha-2 format.
Example: GB.
* Required for payouts

customer.city
string, optional *

Customer city.
A string, must not exceed 255 characters.

Example: London.
* Required for payouts

customer.state
string, optional

Region or state of the customer's billing address.
A string, must not exceed 255 characters.

Example: West Midlands

customer.zip
string, optional

Postcode of the customer's billing address.
A string,must not exceed 16 characters.

Example: B152SA

customer.street
string, optional

Street of the customer's billing address.
Example: Edgbaston

customer.first_name
string, optional *

First name of the customer.
A string, must not exceed 255 characters.

Example: John.
* Required for payouts

customer.last_name
string, optional *

Last name of the customer.
A string, must not exceed 255 characters.

Example: Johnson.
* Required for payouts

customer.day_of_birth
string, optional *

The customer's day of birth in DD-MM-YYYY format.
Example: 21-12-1989.
* Required for payouts

customer.phone
string, optional

Phone number of the customer.
A string, must be a sequence of digits, must contain between 4 and 24 characters, and can start with "+" .

Example: 4402035551981 or +4402035551981

customer.email
string, optional

Email of the customer.
A string, must not exceed 255 characters.

Example: test@mail.com

customer.ip_address
string, optional *

IP address of the customer.
A string, must not exceed 255 characters.

Example: 127.0.0.1.
* Required for payouts

Possible errors

The following error messages can appear after the validity check of the file uploaded to Dashboard has been performed.

Error message Possible reason
File is empty File is empty
Columns are duplicated Parameter has been duplicated
File does not contain required columns Required parameters are missing
Incorrect file format Extension or format of the file is incorrect
File is broken Encoding or data structure is incorrect
Payment method is not available (line# number) Specified payment method is not available
Specified project_id does not belong to specified merchant account Project identifier is incorrect
Project_id is not numeric (line# number) Project identifier is non-numeric
Project_id does not exist (line# number) Nonexistent project identifier has been specified
Payment_id is empty (line# number) Payment identifier has not been specified
Payment with payment_id already exists (line# number) Specified payment identifier has already been registered in the payment platform
Amount is empty (line# number) Payment amount has not been specified
Incorrect Amount (line# number) Incorrect payment amount value
Currency is empty (line# number) Payment currency has not been specified
Incorrect Currency (line# number) Incorrect payment currency value
Invalid date Card expiration date has not been specified or is incorrect
Card.year is in past (line# number) Expired card; expiration year is incorrect
Card.month is in past (line# number) Expired card; expiration month is incorrect