Selling a community or a subscription through a checkout platform splits your business into two halves that do not speak. One half holds the money and the membership. The other half holds the relationship. The gap between them is where the embarrassing failures live: a renewal reminder to a customer who upgraded yesterday, a discount offered to somebody already paying full price, a support answer given by someone who cannot see what was bought.
Whop is a checkout and membership platform used widely by community operators, and Scalegram connects to it so that completed sales land on the client record where the conversation already is. Here is what the connection does and, more usefully, what it deliberately does not do.
One connection, at the account level
Whop is connected once, on the Integrations screen, and that connection belongs to the account rather than to a bot, a campaign or a user. Every other screen in Scalegram selects from what is already connected there. It is a boring rule with a specific payoff: nobody ends up with two half configured connections quietly disagreeing about which sales exist.
Connecting is a privileged action. Teams in Scalegram get read, add, write and delete permissions per area, and the ability to attach a payment source to your client data is one that belongs with the people who carry the account rather than with everyone who can answer a message.
Two channels, because one is never enough
The integration runs on both a push and a pull, and it needs both.
The push is a webhook. Whop sends an event when a purchase completes, and Scalegram verifies the signature on that request before it reads a single field. An unsigned or badly signed payload is discarded, because a webhook endpoint is a public URL and anything that arrives there is a claim until it is proved. The request is acknowledged quickly and the real work is queued behind it, for the reasons set out in webhook safety.
The pull is a scheduled sync against the API, and it exists to cover what the push misses. Webhooks are delivered over the internet, which means they are occasionally not delivered at all: a deploy, a network blip, an outage on either side. A system that only listens will silently lose sales and never know. The sync catches the gaps, which is also what makes a first connection able to bring history in, covered separately in firing past sales correctly.
Matching a payer to a Telegram contact
This is the part that is harder than it sounds. A Whop purchase carries the identity the buyer used at checkout. A Scalegram contact is a Telegram identity. They are the same person often enough to be worth automating and different often enough that pretending otherwise creates a mess.
Matching runs on the identifiers that are actually shared: the email or username used at checkout, and any identifier your funnel carried through from the tracking link to the checkout. When those agree, the purchase attaches to the contact, the record shows what was bought and when, and the stage moves without anyone typing.
When they do not agree, the purchase is held rather than guessed at. A wrong match is worse than no match, because it grants access to the wrong person and puts a false purchase on a real record. Unmatched sales sit in a list to be claimed against a contact by hand, which takes seconds and happens rarely.
Claimed once, however many times it syncs
The webhook and the sync will both see the same sale. So will a retry, a replay and a manual refresh. Scalegram keeps a claim record for each purchase, so the first arrival attaches it and every later arrival is recognised and dropped.
That matters twice. On the client record it prevents a single payment turning into three purchases and an inflated lifetime value. In your ad reporting it prevents a resynced sale becoming a second conversion, which is the difference between a cost per customer figure a media buyer can act on and one they learn to distrust. The conversion event fires server side with its value and the campaign identifiers captured back at the landing page, deduplicated the same way, as described in verified conversions.
Scalegram never touches card details. The payment stays with the processor that took it. What crosses into the client list is the fact of a purchase, what it was, when it happened and how much it was for.
What the assistant does with it
The immediate effect is on tone. Once a purchase is on the record, the assistant answers a paying customer as a paying customer: no pitch for the thing they own, no trial offer, no upgrade prompt aimed at a product they already bought. It knows what stage they are at because the money said so, not because somebody remembered to update a tag.
Access still goes through a checkpoint. A completed sale is strong evidence, and Scalegram is still built so that anything granting access or costing the business money stops for a human yes before it happens. That restraint is the same everywhere in the product, and it is why the storage rule holds too: contacts, purchases, amounts, stages, tags and timing are stored, and the text of your Telegram conversations is not. The reasoning is in the Telegram CRM argument.
"A webhook alone will lose you sales you never find out about. Anyone who has run one without a sync behind it has a story about the week they were down and did not know."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Whop is connected once on the Integrations screen at the account level, and every other screen selects from what is already connected.
- The integration runs a signed webhook and a scheduled sync together, because a listener on its own silently loses sales during any outage.
- Purchases match to Telegram contacts on shared identifiers, and an unmatched sale is held for a manual claim rather than guessed at.
- A claim record means each sale is counted once on the client record and once in your conversion reporting, however many times it syncs.
Frequently Asked Questions
Do I need Whop to use Scalegram?
No. The integration exists for operators who already sell there. A sale recorded another way, including a broker deposit or a purchase confirmed in conversation, lands on the same client record.
What happens when a buyer used a different email than their Telegram account?
The purchase is not matched automatically. It waits in a list of unmatched sales so you can attach it to the right contact yourself, which is safer than an automated guess that grants access to the wrong person.
Does Scalegram see card or payment details?
No. The payment stays entirely with the processor that took it. Scalegram receives the fact of a completed purchase, the product, the amount and the time.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.