I connect websites and web applications to payment processors: Stripe, Moneris, PayPal, Square, and others. One-time payments, memberships that renew on their own, invoices, refunds, and receipts, wired into the rest of your system so nobody has to reconcile them by hand.
Taking a card payment is the easy part. Every processor has a hosted checkout you can put on a page in an afternoon. The work is everything around it: charging the right amount to the right person, recording the payment against the right order or member, sending a receipt with the correct tax on it, and doing something sensible when a card is declined or a renewal fails overnight.
I've built payments into membership platforms, online stores, event registrations, and an awards entry system. Stripe, Moneris, and PayPal are the ones I've integrated most, and I also work with Square, Braintree, Helcim, Authorize.net, and Worldline (formerly Bambora). If your processor has an API, I can work with it.
Choosing a processor
For most new projects I'd start with Stripe. Its API and documentation are the best of the lot, subscriptions and failed-payment retries are built in, and Apple Pay and Google Pay come with it. But plenty of Canadian businesses already have a Moneris merchant account through their bank, often with rates they've negotiated and a terminal at the front counter. If that's you, there's usually no reason to change processors just to take payments online. I'll connect your website to the account you already have.
PayPal is worth offering next to a card form when your customers expect it, which is common with associations whose members pay out of their own pocket. Running two processors side by side is routine, as long as both report into the same place.
What a payment integration covers
Card details go straight from the visitor's browser to the processor through its own secure fields or checkout page, so card numbers never touch your server. That keeps your PCI compliance paperwork to the shortest version and keeps you out of the business of storing card data.
Behind that, webhooks let the processor tell your site the moment something happens: a payment succeeds, a renewal fails, a refund goes through, a dispute is opened. Your system updates the order or membership on its own, and the receipt goes out with your business name, your GST/HST number, and the right tax. Your staff get an admin screen where they can look up a payment, issue a refund, or resend a receipt without logging into the processor's dashboard.
If you're selling products, ecommerce development covers the store around the checkout. If the payments are dues and renewals, membership systems covers the member side.
Fixing an integration that already exists
A lot of my payment work is on systems that already take money and do it badly. Customers get charged twice. Renewals take the payment but never update the membership. Receipts don't arrive, or a plugin stops working after an update and nobody notices for a week. I start with the processor's logs and webhook history, which usually show exactly where it's going wrong, and fix it at the source rather than adding another workaround.
A few examples
Payments are part of most of the platforms I work on, so these are only a sample. On CIM | Chartered Managers Canada, members join and renew through Stripe at a fee set by their membership category and chapter, and get a receipt and a Credly digital badge in the same flow. The Canadian Nutrition Society sells webinars through Stripe at different prices for members and non-members. The RTDNA Canada Awards take entry fees through Stripe with PDF receipts and invoices, and the Model Aeronautics Association of Canada platform runs both PayPal and Stripe.
