A CRM as a workplace, not an address book
Most Pipedrive accounts are a record of work that happened somewhere else. The call happens in a phone system. The booking happens in a calendar tool. The payment happens on a terminal or a payment page. Pipedrive is told about all of it afterwards, if somebody remembers.
That is tolerable when the work is slow. It falls apart when the whole transaction is one phone call, with a customer on the line who wants a slot. Every extra window is a place to lose the thread: a slot that was free thirty seconds ago, a card number read out twice, a booking confirmed in one system and missing from another.
So we design it the other way round. The booking tool we build runs as an iframe inside Pipedrive. The booker stays on the record already in front of them, picks a slot across the six studios, and takes the deposit there. Pipedrive is the workplace rather than the report about the workplace.
What we built
We build a booking tool that loads inside Pipedrive as an iframe, we connect it to PayJunction for the deposit, and we enforce its rules on the server rather than in the interface.
The surface is deliberately small. Six studios, availability, a slot, a deposit. What the booker needs during a call is on one screen and nothing else is. A booking tool that also tries to be a scheduling suite turns into something people click through rather than something they use, and on a live call that difference is the whole product.
The mechanics of putting your own page inside the CRM are ordinary. Pipedrive supports it through app extensions, and the connection back uses the same tokens and webhooks as everything else, which we cover in API tokens and webhooks. What separates a good tool from a dangerous one is not the embedding. It is what happens when a payment does not answer cleanly.
Taking money while the customer is on the phone
The deposit runs through PayJunction, an American payment processor. Charging a card is the part everyone assumes is simple, and on the happy path it is: send the request, get an approval, confirm the booking, carry on with the conversation. The happy path is not the design problem. Neither is a refusal. The design problem is the third outcome, the one most integrations never model at all.
Three outcomes, and they are not interchangeable
Our tool treats a payment attempt as having three possible results, and it never collapses them into two.
| Result | What it means | What the tool does |
|---|---|---|
approved | Money moved. | The booking is confirmed. |
declined | A clean refusal. The processor answered, and the answer was no. | The reservation stays. The booker can try another card. |
error | Unknown. We cannot say whether money moved. | Nothing is retried automatically. A person checks. |
Most payment integrations have two outcomes, because they were written by someone reading a specification in which a timeout looks like a failure. It is not one. A timeout means the request may have been received, processed and charged, and only the reply was lost on the way back. Filing that under "declined" is not a simplification, it is a false statement about the customer's bank account.
Why the server enforces it
The separation is enforced on the server, not only in the interface. If a booking sits in the unknown state, confirmation is refused. There is no path through the screen that talks the system into a confirmation it should not give.
A rule that lives in the front end is a suggestion. It holds until somebody refreshes the page, opens the tool in a second tab, clicks twice on a slow connection, or until a later interface change drops the check without anyone noticing. A rule on the server holds regardless of what the browser does, because the browser is not the thing deciding.
So the confirmation step asks about the state of the booking, not the state of the screen. Unknown means no.
What it costs to get this wrong
If a timeout is reported to the booker as a decline, the booker is being told that it is safe to charge again. That is what a decline means in a phone conversation: no money moved, ask for another card. So they ask. If the first charge did go through, the customer has now paid twice and will find out later, from a statement, and will call about it.
That is real money taken from a real customer while they are still on the phone, in a conversation that was going well a minute earlier. It costs the studio the refund handling, possibly a chargeback, and the trust of somebody in the middle of buying something. All of it traces back to one decision by someone who mapped an ambiguous result onto the nearest familiar one. The alternative is not clever. It is only honest.
What we left out on purpose
There is no automatic retry, and that is the deliberate limitation. On an unknown result a retry is exactly the double charge described above, executed by software instead of by a person, which makes it faster and harder to notice. Somebody has to look at those bookings. That is slower, and it is correct.
We also kept the tool to booking and deposit. It is not a payments dashboard, not a refund console and not a reporting surface. Refunds and reconciliation stay in PayJunction, where the record of what actually happened lives, and reporting belongs to the CRM's own layer, covered in dashboards and reporting. Every feature added to a tool used under time pressure is one more thing to scroll past.
Implementation and building are the same job
This is the case we point at when someone asks whether a Pipedrive partner should also write software. Vita Brevis Fine Art did not need a better configured CRM. It needed a screen that did not exist yet. Configuration alone would have produced a tidy account and a booker with four tabs open.
We build products around Pipedrive for exactly this reason, and the pieces recur across clients. Where a standard product fits, we install it. Where it does not, we build. Both routes are described in our products around Pipedrive.
Sales Surge is a Pipedrive Platinum Partner, in the global top 8 since July 2026, founded in 2023 and based in the Netherlands, with more than 150 implementations delivered. Vita Brevis Fine Art is an American client and PayJunction is an American processor, so this build sits squarely inside the work described in Pipedrive implementation in the USA.
Sales Surge built this. We implement Pipedrive and we build the tooling that has to sit around it, which is the only reason a booker can take a slot and a deposit in one call without leaving the CRM. If your team is working around Pipedrive instead of inside it, that gap is usually buildable. What we do is on sales-surge.io.
Questions
Can you run your own application inside Pipedrive?
Yes. Pipedrive lets a custom app load your own page inside the CRM as a panel or a modal. That is how the Vita Brevis Fine Art booking tool works: it is our application, rendered in an iframe, sitting on the record the booker is already looking at.
Why not treat a payment timeout as a decline?
Because a timeout means the request may have been received, processed and charged, and only the answer was lost on the way back. The money may already be gone. A decline tells the booker it is safe to charge again. On a timeout that is not safe, and the customer is still on the phone.
Does the tool retry a failed payment automatically?
No, and that is deliberate. On an unknown outcome an automatic retry is a double charge executed by software instead of by a person, which makes it faster and harder to spot. Bookings in the unknown state wait for a human to check what actually happened at the processor.
Why enforce the payment states on the server rather than in the interface?
Rules that live only in the front end are suggestions. They survive until someone opens a second tab, refreshes, double clicks on a slow connection, or until a later interface change quietly drops the check. We enforce the separation on the server, so a booking in the unknown state is refused confirmation regardless of what the browser does.
What happens to the reservation when a card is declined?
The reservation stays. A decline is a clean answer from the processor, so nothing is in doubt and nothing needs to be undone. The booker asks for another card and tries again in the same call, with the slot still held.