Keep payment status close to the transaction.
The checkout takes a few seconds. The record behind it lasts much longer: payments fail, arrive twice, cover part of a balance or need refunding. We build the part that comes after the pay button.
What goes wrong after "Pay now".
Each of these happens in normal operation, and each needs a planned path.
The browser closes
The customer pays, then closes the tab before returning to your site. The money was collected; your platform never saw the success page.
The event arrives twice
Payment providers can send the same confirmation more than once. Counting it twice means a booking marked overpaid or an order shipped twice.
Confirmation is delayed
Some methods, such as bank transfers, confirm minutes or days later. The order needs a pending state staff understand.
The amount doesn't match
A customer pays less than the balance, or more. Someone has to decide what happens next, and the software has to show them.
Which system says it's paid?
We agree the source of truth for payment status before building anything. A customer reaching a success screen after a redirect doesn't, on its own, prove money was collected. The confirmation that counts comes from the payment provider directly to your platform, and is then matched to the right order, booking or account.
Your team should be able to open any record and see what was collected, what is pending and what still needs checking. When the provider and your platform disagree, the mismatch should appear in a list someone reviews, not surface weeks later in the accounts.
Collecting money in more than one shape.
Instalments and part-payments. A property booking may start with a token amount followed by milestone payments over months. A training course may take a deposit, then the balance before the start date. We model the schedule, record each payment against it and show the outstanding balance at any moment.
Easy Inventory, a platform we built for our client, keeps payments together with inventory, bookings and channel partners for builders and developers.
Recurring billing. Subscriptions run on the payment provider's recurring features plus your commercial rules: renewal dates, proration, retries and what happens when a card fails. The rules side is covered under subscription platforms.
Invoices and tax. Invoice numbering, tax details such as GST where they apply, credit notes for refunds, and a place for customers to download what they've been billed.
Plan the incomplete transaction.
Before integration starts, we go through these with you and whoever looks after your accounts.
- How each payment is matched to its record, and what happens to one that can't be matched.
- What staff see while a payment is pending or delayed.
- How repeated events from the provider are recognised and ignored.
- Who can issue a refund, up to what amount, and how it shows on the original record.
- How the provider's settlements are reconciled against your own records.
- Which provider fits your markets and methods, such as UPI, cards or bank transfer.
Payment questions from owners.
Can payments be collected in stages?
Yes. We build the instalment and balance rules you agree around the transaction, with reminders before each due date if you want them.
Can you support recurring billing?
Yes. We plan subscriptions around what your payment provider supports for recurring charges and the commercial rules you agree, including retries and what customers see when a renewal fails.
Do you hold the money?
No. Payments go through a licensed payment provider you hold an account with, under its own charges and terms. We build the integration and the records inside your platform.
Can you add online payments to a platform we already have?
Usually. We review how orders or bookings are stored today and connect the provider to them. Booking flows are a common case; see booking platforms.
Tell us how money moves today.
Describe a typical order or booking from payment to reconciliation, and we'll mark the gaps.