Split processing fees and VAT

Two controls for one order#

The processing fee control allocates the whole acceptance fee, including both its percentage and fixed components. The VAT control allocates only tax. Neither control changes the tariff, tax rate or base product price.

Fully left assigns the cost to the customer; fully right assigns it to the merchant. Labels show both parties’ exact percentages and monetary amounts. Customer, Split equally and Merchant presets provide a quick choice.

• The customer share is added to the checkout total.
• The merchant share is deducted from the base order price.
• SBP and cryptocurrency have zero VAT, so the VAT control does not affect their total.
• Buttons and sliders work with the keyboard; animation is not needed to understand the result.

One base price, two separate costs#

International cards and Alipay cost 10% of the base price plus $0.50, with VAT of 16% of the base price. SBP costs 8% and cryptocurrency costs 4%; neither has VAT under the published pricing model.

VAT is added from the base price, not extracted using 16/116. The fee is not recalculated on a total that includes VAT or the customer fee share. Kevmi’s commission is already included in the published tariff; another 5% is not added.

fee = roundHalfUp(base × rate / 100) + fixed
vat = vatApplies ? roundHalfUp(base × 16 / 100) : 0
customerFee = roundHalfUp(fee × feeCustomerPercent / 100)
customerVat = roundHalfUp(vat × vatCustomerPercent / 100)
merchantFee = fee − customerFee
merchantVat = vat − customerVat
customerTotal = base + customerFee + customerVat
merchantNet = base − merchantFee − merchantVat

Allocating a $5 card order#

Every example below uses a $5.00 base price, a $1.00 total card fee and $0.80 VAT. The percentages change only who covers those costs.

Rounding without losing a cent#

Amounts are integer minor currency units. The total fee and total VAT are rounded separately first. Each customer share then uses half-up rounding, and the merchant receives the exact remainder of that cost. The two shares therefore always add up to the original amount.

For a one-cent cost split 50/50, the customer is allocated one cent and the merchant zero. The percentage remains 50%, while monetary amounts reflect the currency’s available precision. The server rejects calculations with negative merchant proceeds.

Set the split through the API#

Send vatCustomerPercent and feeCustomerPercent as integers from 0 to 100. Each applies to the invoice being created. Empty strings, fractional percentages and out-of-range numbers are rejected.

Omitting feeCustomerPercent assigns the whole fee to the merchant. Omitting vatCustomerPercent uses the legacy vatPayer field or the account default. Legacy customer and merchant values correspond to 100% and 0% customer VAT. Do not send conflicting vatPayer and vatCustomerPercent values.

Responses describe an intermediate VAT share as vatPayer=shared. Use the numerical percentage for new requests; shared is not accepted as the legacy vatPayer input value.

{
  "title": "Design project · order 1042",
  "description": "One-time payment for the agreed design work",
  "amountMinor": 500,
  "currency": "USD",
  "methods": [
    "card",
    "alipay"
  ],
  "vatCustomerPercent": 100,
  "feeCustomerPercent": 0,
  "orderId": "order-1042",
  "metadata": {
    "campaign": "autumn"
  }
}

Terms stay with the invoice#

The invoice freezes the amount, currency, methods and both shares. Changing store preferences does not modify issued links. Sliders calculate the allocation; live execution depends on the connected channel’s capabilities.

For a new live card or Alipay payment, the current gateway supports only feeCustomerPercent=0 and vatCustomerPercent=100: the merchant covers the entire processing fee and VAT is added in full for the customer. Other shares can be saved and calculated on an invoice, but execution is blocked with unsupported_allocation. The server never silently changes saved terms. SBP and USDT crypto payments support every processing-fee share and have no VAT.