--- title: "Collect custom fees" slug: "custom-fees" updated: 2026-07-09T15:09:35Z published: 2026-07-09T15:09:35Z canonical: "www.documentation.paynetics.digital/custom-fees" --- > ## Documentation Index > Fetch the complete documentation index at: https://www.documentation.paynetics.digital/llms.txt > Use this file to discover all available pages before exploring further. # Collect custom fees The example below represents the flow for collecting a FX fee for an internal transfer: ![A diagram of a bank transfer Description automatically generated](https://cdn.document360.io/4bc02332-492c-444b-85e7-bf524fc0dcb5/Images/Documentation/custom-fees-image-il1d4rjv.png?sv=2026-02-06&spr=https&st=2026-11-15T00%3A38%3A23Z&se=2026-11-15T01%3A38%3A23Z&sr=c&sp=r&sig=mBkM%2BLufzoq836vtLssMzGXUiQ3oBhT%2ByfUyTba3phA%3D) 1. The customer makes an internal transfer from a Payment Account in EUR to a payment account in GBP. 2. You execute a fee transfer from the payment account of the end-customer to a Fee Collection Account created by Paynetics. You won't have access to make any type of transfers from the Fee Collection Account. When you are creating the fee transfer request you must: 1. Specify the Balance Token of the Fee Collection Account, it will be provided by Paynetics. 2. Specify the type of the transfer as Fee transfer by setting the code field to ST013. 3. Specify the transfer for which you are collecting the fee by setting the Token of the transaction you are collecting the fee for (the one from point 1) in the link attribute of the request. In case you are collecting a fee not related to a particular transaction (e.g. monthly subscription fee) you must not add this attribute in the request. 4. Specify the fee type that you are collecting in the reference fee. In this case "FX Fee" ## Example fee transfer request ```json {   "amount": 1.23,   "currency": "EUR",   "code": "ST01", The code specifying the transfer as Fee transfer.   "link": "520bec3b-8051-4a2b-928c-81d32b6bfa41",  The token of the transaction that you are collecting the fee for. The transation from poin 1 in the example.   "reference": "FX Fee", - The type of the fee collected   "debtor": {      "balance": "444f4f2c-6a05-43bb-93ab-7ab76ce5658c", - The balance token of the end-customer account that you are collecting the fee from   },   "creditor": {      "balance": "444f4f2c-6a05-43bb-93ab-7ab76ce5658c", - The balance token of the Fee account that Paynetics has provided for you   } } ``` ## Rolling out custom fees Populating the Link and Reference fields ## **Transaction fees** If you are collecting a transaction fee, you must populate: **Link** field → with the ID of the transaction they are collecting a fee on **Reference** field → with the type of fee being collected ## **Account fees** If you are collecting an account fee, you must populate: **Link** field → with the ID of the account they are collecting a fee on **Reference** field → with the type of fee being collected ## Fees approval You must submit all custom fees that you plan to collect from end-customers. These fees must be reviewed and approved by Paynetics before launching them. All fees collected must be present in your T&C. As a reminder, all fees, must abide by the following: - **Fair Billing Practices**: Ensure that fees are collected in a transparent and fair manner, in accordance with consumer protection laws. - **Disclosure Requirements**: Clearly disclose all fees in your T&C and charges to customers before they agree to the service. - **Financial Statements**: Ensure that all fees are accurately reflected in financial statements. - **Non-Discrimination**: Ensure that fee structures do not discriminate against any group of customers. - **Proper Taxation**: Collect and remit applicable taxes on fees collected from customers. Ensure compliance with tax reporting requirements for all jurisdictions in which you operate. ## Fees testing You must test the fee collection implementation extensively. Once you have done this you must notify Paynetics. You must provide information on the test that you have passed and the payment accounts that you have used for the tests. Paynetics will review your tests and provide greenlight for a launch date. ## Fee refunds Refunding fees is a manual process, where you need to contact our Customer Support who will open a Jira ticket for you, which will be addressed by our internal teams. Within the Jira ticket you need to provide: - The ID of the fee transaction - The reason for the Refund - If the refund is full or partial. For partial refunds, you need to specify the amount. The standard, most commonly used Account type in the Paynetics platform. Payment accounts provide full current-account functionality: inbound and outbound transfers, card issuance and linking, internal transfers, and one or more Balances depending on Programme configuration. An **Account** is a payment or e-money account used to hold funds and execute transactions. Accounts are created under a specific instance and program and are associated with either a user or a merchant. They provide the logical structure under which balances, cards, and transactions are organised. Common account purposes include: - executing card payments and transfers - holding settlement funds - pre-funding services such as OCT An account acts as a container for balances rather than holding funds directly. The unique internal identifier for a Balance, used in API operations when targeting a specific currency balance within an Account. **Tokens** are unique identifiers used throughout the Paynetics platform to securely reference objects. Tokens exist for instances, programs, accounts, balances, cards, merchants, and transactions. They are mandatory in API calls and ensure secure identification without exposing sensitive data, accurate routing of operations, and consistent handling across services. For example, a balance token specifies which funds are debited or credited, a card token identifies the card used in a transaction, and a merchant token links activity to a specific merchant. A merchant-initiated transaction that returns funds to a cardholder after a completed and settled payment. A refund is processed as a new, separate transaction and does not cancel the original authorisation. Distinct from a reversal, which cancels an authorisation before settlement.