We didn’t move all our projects to PaymentKit at one time. That was something we agreed on fairly early, even though we were hurrying to get the integration running. We had different subscription setups to consider, and we didn’t want to discover an issue with customer access after real payments had already started arriving.
Our original plan was to configure the basics, test everything in the sandbox, and launch with one project. It sounded straightforward when we first communicated about it. Once we got into the details, though, we found ourselves spending more hours on what happened after checkout than on the payment itself.
The product catalog was the first thing we agreed on, and I remember thinking we’d get through it pretty fast. We already had our prices and subscription plans, so how much was there to find out?
Quite a bit, apparently. Once we started managing everything in PaymentKit, we ran into little questions about billing arrivals and how certain plans should be presented at checkout.
A few times, we had to go back and check how things happened in our existing projects because nobody could remember the specific events. Most of the setup was straightforward, but we ended up spending more time reviewing our ancient pricing decisions than we’d expected.
Next came the processor integration. We’d worked with payment processors before, so the general idea was identical. What was different was having billing and processor configuration managed through the PaymentKit tool instead of building everything around one processor connection.
We spent time reviewing the documentation, checking which settings belonged in PaymentKit and which parts our application would continue managing. It wasn’t a complicated variation on paper. We still wanted everyone working on the integration to understand it before testing started.
We got our first successful sandbox payment working adequately, and I remember thinking we were making good progress. Then someone brought up what would take place if a customer closed the checkout page halfway through. We hadn’t particularly discussed that during the first setup of SaaS products.
So we went back and tried it, along with a few other issues where payments didn’t go as expected. Some tests were worth running more than twice because the first result didn’t tell us everything we wanted to know. It took longer than we expected, although none of us wanted to find these issues after launching.
The account updates shifted into a bigger discussion. We could see that a payment had succeeded in PaymentKit, but we still had to make sure our application received that information and updated the customer’s subscription perfectly.
What if the notification was received late? Would the customer see their payment as completed while their account still showed the previous status? We spent quite a bit of time working through those questions. There was no point in getting proper checkout if customers ended up reaching support because their subscriptions hadn’t updated.
After a while, we shifted how we tested things. Instead of running a payment and immediately moving on to the next issues, we started checking what happened to that transaction afterward. We’d open the billing records, compare them against our application, and occasionally repeat a test when something wasn’t proper.
The sandbox made that possible without powering real cards. By the time we finished, we had a much better knowledge of how the different parts of the integration were supposed to perform together. And we had a few more things on our launch checklist than we’d expected.
Webhooks took more effort than we’d expected. PaymentKit could send notifications about payment and subscription events, but our application had to define what to do with that data. We didn’t want an account update happening two times because the same event was happened again.
Nor did we want customer access relying entirely on someone returning to the website after checkout. We reviewed how notifications would connect our application and how we could verify the current data through the API. Those checks became an important part of our preparation for production.
Checkout itself required another review, too. We checked the information customers would see and how the payment flow connected back to their accounts. We were specifically interested in what happened when a customer left checkout before completing a transaction.
Some questions were easier to answer by reviewing the process ourselves than by reading another page of documentation. We made several passes through the flow before moving ahead.
By the time we were ready for production, we’d planned our rollout in five stages:
I think we were all a little more nervous about the first live project than we thought. We’d gone through the tests, checked the settings, and had no particular reason to delay the launch. Still, watching real payments come through felt different from working in the sandbox.
We found ourselves checking the billing records more often than expected, then opening customer accounts to make sure subscriptions had updated perfectly. Even after the first few payments went through without any visible issues, we kept an eye on things.
Nobody actually said, “Okay, we’re done here.” At some point, though, we noticed we weren’t checking every transaction anymore. The connection had started to feel less like something we were testing and more like a usual part of how our project worked.
By the time we switched on to the next project, we weren’t second-guessing every step anymore. We had our notes from the first rollout, knew where to look when anything didn’t work, and could reuse quite a bit of what we’d already accomplished.
Of course, the second project brought up a few challenges of its own. The subscription setup wasn’t quite the same, and we had to go back and check how often account updates should work. But those discussions felt different from the ones we’d had at the start. We weren’t trying to figure out PaymentKit from the beginning anymore. Most of the time, we were figuring out how to make the existing setup work for a different project.
Looking back, the most ideal decision was starting small. We could have focused on getting several projects live as quickly as we could, but that would have made troubleshooting harder. Working through one integration first let us separate PaymentKit configuration from the responsibilities of our owned application, just like the top software development companies.
We also learned that testing a payment and testing a whole billing workflow are very different tasks. If we were starting again, we’d probably spend less time worrying about the first successful transaction and more hours checking what happens afterward. That’s where most of our essential integration questions came from.
Ans: We launched PaymentKit with only one project first because starting with one project helped us identify issues and test integration before reaching other users.
Ans: We focused on payment outcomes, subscription updates, checkout behaviour, and webhook notifications during PaymentKit testing.
Ans: Our biggest lesson from using PaymentKit was that testing the complete billing workflow is just as important as confirming a successful payment.
