Processing fees paid by the buyer
JomForm can pass the CHIP processing fee to the buyer, with one rate per payment method that you set yourself. The buyer sees the method, the fee and the final total before paying, and the amount is calculated so that you still receive the price you asked for — at most one sen short, from rounding. This page documents how the rate works, what the buyer sees, and what lands on the sale.
Setting it up
1. Decide whether you may pass the fee on
Passing a card surcharge to the buyer is restricted by card-network and acquirer rules, and by consumer law in Malaysia the price shown must be the price paid. That is your call as the merchant: JomForm does not block the feature, it makes the disclosure explicit. The acknowledgement below is the record that you took that decision.
2. Type your own rate per payment method
Open Settings → Payment fees. Every CHIP payment method has its own row: FPX, Card, e-Wallet and DuitNow QR. Each accepts a fixed amount in sen (RM1.00 = 100) and/or a percentage in basis points (100 = 1%, 140 = 1.4%, 200 = 2%). Both are optional and can be combined: RM1 fixed plus 1.4% is a valid rate. The rate is the one YOUR acquirer charges you — JomForm does not guess it, and nothing is filled in for you.
3. Tick the acknowledgement
"I understand this processing fee is passed on to the buyer and is subject to acquirer/card-issuer rules." The sentence is served by the API and recorded with your account, the time, and who accepted it. Until it is ticked, no fee reaches a buyer even if the rates are saved — the checkout simply charges the plain price.
4. Pick which forms carry the fee
A workspace-wide rate applies to every published payment form. A single form can opt out: set its fee override to off (Form Settings, or PUT /v1/rest/forms/{id}/fee-override), and that form charges no fee while the rest of the workspace keeps its rates. The override is per form, not per buyer, so the same form behaves the same way for everyone.
5. Watch what the buyer sees
On the checkout page the buyer chooses the payment method. The page shows the items subtotal, a separate processing-fee row naming the method and its rate, and the final total — before the Proceed to Payment button. If only one method carries a rate it is preselected, so there is no extra click. With more than one, the buyer must choose, and an order that names none is refused rather than priced with a guess.
Why the total is not “price plus percentage”
| RM1,000 at 1% | Total charged | Fee | You receive |
|---|---|---|---|
| naive: price + price × rate | RM1,010.00 | RM10.10 | RM999.90 — 10 sen short |
| JomForm gross-up | RM1,010.10 | RM10.10 | RM1,000.00 |
The rule is the smallest total where the fee taken from it still leaves your asking price. It holds for every combination of fixed amount, percentage and price, and never leaves you more than one sen short.
What lands on the sale
The total is grossed up, not added to
CHIP charges its fee on the amount the buyer actually pays, not on your price. Adding "price + price × rate" therefore leaves you short by the fee charged on the fee itself: 10 sen on RM1,000 at 1%. JomForm solves it the other way round — it finds the smallest total where, after the fee is taken, you still receive your asking price. RM1,000 at 1% is charged to the buyer as RM1,010.10 (fee RM10.10), and you receive RM1,000.00. The most you can be short is one sen, from integer rounding.
The method cannot be switched at the CHIP page
Because each method has its own rate, the payment is created for the one method the buyer chose: the CHIP purchase whitelists that method only, and its amount is the server's grossed-up total. A buyer who chose (say) FPX at RM1 cannot change to Card at 2% after seeing the charge, and cannot pay an amount other than the one the JomForm page displayed.
The server re-checks everything
The method and the total from the browser are treated as claims, never as inputs. The server resolves the rate from your stored settings, recomputes the total, and refuses (HTTP 400) an order whose method is not active or whose total does not match what the page showed — for example because you edited a price or a rate while the buyer was filling the form. A refusal asks the buyer to reload; it never silently charges a different amount.
The fee is frozen on the sale
When the sale is created it records the fee, the method and the rate that applied. Changing your rates later does not rewrite a past sale, and a receipt reprinted months later prints the rate the buyer actually paid. On the sale the total is items subtotal + shipping − discount + processing fee: the fee is its own component, never folded into an item's price, and the receipt and PDF show it as its own line ("Processing fee — Card 1.00%: RM 10.10").
Refunds never recalculate the fee
CHIP does not return the processing fee it charged you, and JomForm never recalculates, re-estimates or adds back a fee on a refund. A full refund returns the amount the buyer actually paid — which includes the fee — so the buyer is made whole and you still carry CHIP's charge; a partial refund returns the amount you choose. Either way the sale keeps showing the fee you bore at the rate in force when the buyer paid, and a later rate change never rewrites it. Whether a full refund should include the fee is your refund policy's decision; the system does not deduct it silently.
e-Invoice
The processing fee is part of the amount charged, so it is never hidden inside the total: it is its own line on the receipt and on the receipt PDF, alongside the frozen rate. JomForm records the fee as a distinct sale component (fee_sen, separate from subtotal / shipping / discount), so an LHDN line-item document can carry it without reshaping past records. SST is not calculated for this fee in the current release.
Managing it with an agent (MCP)
The same rates are available over the JomForm MCP, so an agent can read them or set them for you. Money is integer sen and the percentage is basis points (100 = 1%); enabling a method requires the acknowledgement in the same call, exactly as the settings page does.
get_payment_fees
Read every method's stored rate (enabled or not), the fixed amount in sen and the percentage in basis points, plus whether the account has accepted the pass-on acknowledgement and who accepted it.
set_payment_fees
Replace the whole rate set in one call. A method the payload omits is deleted. Enabling a method requires acknowledged=true — the same sentence the settings page shows — and the tool records who set it and when.
The same settings are on the REST API as GET /v1/rest/settings/payment-fees and PUT /v1/rest/settings/payment-fees, with the per-form switch-off at PUT /v1/rest/forms/{id}/fee-override.