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.
PipeDriven is powered by Sales Surge, and the build described here was done by the Sales Surge team. Sales Surge is a Pipedrive Platinum Partner, in the Top 8 worldwide since July 2026, and has delivered more than 150 implementations. It was founded in 2023 and is based in the Netherlands. 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.
What Vita Brevis said
The review below is on the Pipedrive Marketplace listing, quoted word for word. It is about working with the team as a whole, not about the booking tool in particular, and we read it that way. It is one of the 11 reviews behind the 5.0 rating on the listing, and the rest are on our reviews page.
“I believe most small businesses and some large ones get stuck at a level, and you do not know how to get to the next. We were there. When we first met with Sander and Sales Surge, we had hope! When he gave us the proposal, we were not just sold, but now we KNEW how to get to the next level! But the measure of a company and a man does not come when all is well, so when the S hit the fan, we were in complete awe of how well Sander performed! You can not go wrong with Sales Surge and with Sander!”
What to take from this case
| Question to ask | The answer in this build |
|---|---|
| Where does the work actually happen? | On a phone call, so the tool lives on the record the booker is already on |
| Which outcomes can a payment have? | Three: approved, declined, error. Never collapsed into two |
| Where are the rules enforced? | On the server, so a second tab or a double click cannot get around them |
| What stays out of the tool? | Retries, refunds, reconciliation and reporting |
When a custom tool is the wrong answer
Most teams do not need to build anything. If the work can be done with a standard integration from the Pipedrive Marketplace, install that. A custom tool earns its place when the transaction is short, happens under time pressure and spans systems that a standard connector would leave on separate screens. Where that is not the case, the DIY versus partner decision and the automations that already ship with Pipedrive come first.
If your team is working around Pipedrive instead of inside it, that gap is usually buildable, and a call is the quickest way to find out.
Last reviewed: October 2026
Want this for your team?
Book a 30 minute call and bring your pipeline. PipeDriven is powered by Sales Surge, and the projects behind these guides are listed on www.sales-surge.io.