The problem
This association’s payment processor charges a transaction fee on credit-card payments but not on cheques. Its Swoogo registration form quoted one flat price regardless of how someone planned to pay, which meant either card payers weren’t covering the actual processing cost, or cheque payers were being charged a fee that didn’t apply to them.
The approach / solution
- Built a payment-method selector directly on the registration form, letting a registrant choose between cheque and credit card.
- Wired a fee calculator underneath it: selecting credit card recalculates the total to include the processing surcharge before the registrant confirms; selecting cheque leaves the listed price untouched.
- Documented the logic in a standalone integration reference so the fee rule stays traceable to this client’s specific processor terms, not buried in a generic snippet.
Outcome / result
The selector and calculator run live on this client’s registration form. A registrant who pays by card sees the correct card-adjusted total. Someone paying by cheque never sees that fee at all.
Why it matters for enterprise event-tech
Getting a processing fee right at the point someone chooses how to pay is a small detail with real money behind it across hundreds of registrations a year. It’s the kind of correctness a financial-services client notices immediately if it’s missing.
