Outcome

Members pay the way their finance department needs them to pay

Payments as a member experience problem, not just a finance one

PaymentsiMISeCommerceIntegrationFinance
All Case Studies

The outcome

Most member transactions don’t fail at the decision to pay. They fail at the decision about how to pay.

A practitioner whose firm pays their practising certificate fee can’t put it on a personal credit card and reclaim it, the firm needs the invoice in their name. A corporate member whose membership is funded by their employer needs the invoice to go to accounts payable, not to the individual member. A small business member’s accountant only processes payments by EFT, with a remittance advice. A self-funded sole trader is happy to put it on a card.

When the payment options on offer don’t match how the member’s finance reality works, the member doesn’t pay. They put it down. They forget. They call the office to ask whether there’s another way. The transaction that should have closed in two minutes drifts for two weeks.

The outcome here is to give members the payment options they actually need, not just the ones the AMS came with out of the box. Card payment for the member who pays with a card. Invoice-to-firm for the member whose firm pays. EFT with a clean reference for the member whose accountant requires it. Special pricing rules for bundles, member tiers, or one-off offers. Granular visibility for the finance team about what worked, what failed, and why.

What payment looks like to the member

The member finishes a renewal, an event registration, or a CPD purchase. The payment screen knows them. It offers the options that match their member type and history. If they paid with a particular card last year, the option to use it again is available, securely. If their firm typically pays for them, the invoice my firm option is there, with the firm’s billing address pre-filled. If the bundle they’ve selected qualifies for a special price, the price reflects it.

If their card declines, they see a useful message. Not “transaction failed”, but a message that distinguishes between “your bank declined this” and “the card details don’t match” and “this card has expired.” They can correct what’s wrong and try again, in the same session, without starting the whole transaction over.

The receipt arrives immediately. The tax invoice is correct, addressed to the right entity, with the right ABN treatment. If the firm is the payer, the receipt goes to the firm’s accounts contact as well as the member.

What payment looks like to the team

The finance team stops being a reconciliation team. The match between what the AMS says was paid and what the gateway says was paid is automatic, with full visibility on both sides. Declined transactions are recorded with reasons, classified, and trendable. Patterns emerge: a particular card type declining at a particular volume, a particular bank’s anti-fraud rules tripping at month-end, a corporate billing address consistently failing because the format is wrong. The team can do something about these patterns rather than process them one transaction at a time.

For the membership and events teams, the payment-side friction stops being a member-experience problem. They don’t field calls from members trying to figure out why their payment didn’t go through. They don’t manually reissue invoices because the original went to the wrong address. They don’t manually mark transactions as paid in the AMS because the gateway didn’t push a clean record back.

Why this was hard before, and why it isn’t now

The standard payment integration in many AMS platforms is intentionally simple. Card details go to the gateway, the gateway returns approved or declined, the AMS records approved or declined. Anything more nuanced, the reason a card was declined, granular reconciliation, multi-payer billing, sophisticated pricing rules, has historically required custom development per gateway, per AMS, per project.

What’s changed is the emergence of standardised gateway provider patterns that sit between the AMS and any modern payment gateway and capture the richer data that gateway already provides. Combine that with a CMS-based payment experience that can encode pricing rules without a custom build, and the payment surface becomes a designable thing rather than a fixed feature.

The other change is that members have got pickier. The expectations set by Stripe, PayPal, and modern banking apps mean that an AMS payment screen from 2015 feels like a relic. Bringing the payment surface up to current expectations is no longer optional.

The proof: associations running this outcome with 3DN

3DN iMIS Gateway Provider Model, the underlying pattern

Clients had been asking why iMIS couldn’t tell them more about a credit card rejection. In fundraising, the why behind a decline is critical. There’s also analytical value in capturing rejection reasons over time. The standard iMIS CC Gateway interface didn’t allow it, nothing was saved if the card declined.

3DN built a Gateway provider that sits between iMIS and the credit card gateway and, where the gateway supports it, interacts with the gateway at a more granular level. It captures rejection reasons, allows classification of rejection types, and gives finance teams full reconciliation. iMIS can still behave in its simple way for routine transactions, but the association now has a record of every transaction passed to the gateway and the outcome.

Legal Practice Board of Western Australia, the multi-payer story

The renewal flow at LPBWA recognises that legal practitioners are paid for in multiple ways. Some pay with a personal card. Some have their fees paid by the firm and need the invoice issued to the firm directly. Some have their firm bulk-pay for multiple practitioners. The Service Hub gives practitioners the right options based on their context, and lets firms track and pay for multiple practitioners at once.

Australian Institute of Superannuation Trustees, the special-pricing story

CPDforSuper supports bundle pricing, get three webinars for the price of two, alongside member-and-non-member pricing differentials. The shopping cart pattern wasn’t sufficient because members might want to buy a single item without being forced into a multi-item flow. A small amount of customisation to Kentico’s eCommerce, integrated with iMIS for payment processing and tax invoice generation, gave AIST the pricing flexibility they needed without the cost of a custom build.

AIM WA, the cleaner-payment-with-cleaner-data story

AIM WA’s online registration boom was as much a payment experience improvement as a registration experience improvement. Real-time integration meant invoices were correct, payments reconciled cleanly, and the data quality of the contact records improved because the payment captured them properly.

Where this outcome applies

Every association whose members pay something. The urgency is highest where:

  • Multiple payer types are common (member, firm, employer, corporate sponsor)
  • Pricing is rules-based rather than flat (bundles, tiers, time-limited offers, member-versus-non-member)
  • The transaction value is high enough that a failed transaction is worth chasing (CPD bundles, conference registrations, annual fees)
  • The finance team’s reconciliation burden is high enough to be a measurable cost
  • Compliance or audit defensibility around financial transactions is non-trivial

The 3DN iMIS Gateway Provider model is the underlying pattern that gives finance teams granular visibility on what worked, what failed, and why. The Legal Practice Board of Western Australia is the proof of the multi-payer story, with practitioners, firms, and bulk-paying employers all accommodated in the same renewal flow. The Australian Institute of Superannuation Trustees demonstrates the special-pricing story, with bundle and member-versus-non-member pricing rules expressed in the AMS and respected on the payment surface. AIM WA shows the relationship between cleaner payment and cleaner data, which is what makes the whole pattern stick.

The tools that supported this outcome were iMIS as the system of record for member payments, the 3DN iMIS Gateway Provider for granular gateway integration, Kentico as the eCommerce surface where pricing rules and payment options are presented, payment gateway integrations for the actual point of authorisation, and reporting tools like Power BI for the visibility layer that turns reconciliation into insight. A clean payment outcome is the result of the design, the right options for the right member with full visibility on both sides, more than any specific tool.

Have a similar challenge?

We'd love to hear about your association's goals and explore how we can help.

Book a Walkthrough