FanCentro Clone Script: Running a Paid DM Inbox That Pays

Most founders planning a creator platform budget carefully for the feed and treat the inbox as a chat widget to bolt on later. That order is backwards. The direct message thread is where the highest-margin money moves: it is the only surface where price is set per recipient, per moment, with no catalog page and no subscription tier in the way. It is also the surface that breaks first, because chat and payments have almost nothing in common once you look at the data.

This post is about that one surface. Not the feature list, not the price tag; the commercial overview and build scope live on the FanCentro clone hub. What follows is the engineering shape of a paid DM inbox as implemented in the reference platform we deploy: which columns hold the lock, where the money is recorded, how media is served, what the queue worker does to a mass send, and the behaviors the documentation leaves for you to decide.

Every claim below traces to the platform’s own schema, API and architecture documentation. Where it is silent, this post says so. Wider context for the category sits in our creator economy industry practice.

What does a priced message actually look like in the data model?

The messaging domain in the reference schema is eleven models wide, and the center of it is a single messages table. One row is one message: a conversation foreign key, a sender foreign key, body text, a type enumerated as text, image, video, audio, file or gift, a reply-to pointer, a status moving through sent, delivered and read, and a soft-delete timestamp.

Two of its columns are the entire paid-messaging feature: a nullable price decimal and an is_paid flag defaulting to zero. That is the whole mechanism. A creator attaches a price, the recipient sees a locked state, and on payment the flag flips.

What matters is what the row does not have. The feed post table in the same schema carries four monetization columns: a paid flag, a price, a locked enum with yes and no values, and a visibility enum with public, private and subscribers states. The message row carries two of the four. There is no lock enum and no visibility enum on a message.

So “is this message locked?” is derived, not stored: it is answered by testing whether a price exists and the paid flag is still zero. That works until someone needs a message priced but temporarily unlocked for a promotion, or free but restricted, or locked at zero as a teaser. None of those states can be represented without adding a column, and retrofitting lock state onto a table already holding millions of rows is a migration you schedule, not a patch you ship.

Where does the money from an unlocked DM get recorded?

All money routes through one central transactions ledger: payer and recipient, amount and currency, gateway name, external gateway reference, a status machine covering pending, completed, failed, cancelled and refunded, and a type. Documented type values include subscription, tip, purchase, withdrawal, refund, gift, ppv and shoutout. The documented message flow confirms a paid message writes a transaction row alongside the message row.

The ledger is clean. The entitlement side is ambiguous.

The platform has a dedicated pay_per_views table for unlock records, built as a polymorphic link with a payable_type and payable_id pair. The schema reference enumerates that type twice, and in both places lists posts, media and reels. Messages are not in that list. The entity-relationship document, written separately, describes the same table in prose as monetizing “content and messages.” Those two statements do not agree, and the difference is not cosmetic.

If a DM unlock writes no pay_per_views row, the only record that a fan bought a particular message is the paid flag on the message itself. That renders the thread correctly. It is not obviously enough to populate a purchased-content view, and the API does expose one. Settle this in code before launch: does unlocking a message create an entitlement row, or is the message row the entitlement? Refund handling and purchase history both depend on it.

Put the rest of the asymmetry in front of your technical lead before the first sprint. Every row below comes from the schema.

Concern	Priced feed post	Priced direct message	What you have to decide
Lock state	Explicit locked enum, yes or no	Not stored; derived from price plus paid flag	Whether you need lock states price alone cannot express
Audience gate	visibility enum: public, private, subscribers	No visibility column; audience is the conversation	Whether a priced DM should reach a non-subscriber at all
Paid marker on media	Attachment row carries its own paid flag	Attachment row carries no paid flag	Whether per-attachment unlock is ever needed in a thread
Documented unlock flow	Five documented steps, ending in an unlock record	No equivalent step-by-step flow documented	Who writes and reviews the message unlock path
Admin price guard	Minimum and maximum PPV price, documented per post	Not stated as binding on a message price	Whether the guard needs extending to the inbox
Per-item analytics	Daily rollup includes a PPV unlock counter	Daily rollup counts message volume only	Whether you can run the inbox without unlock-rate data
Deletion	Removal with reason code through admin takedown	Soft delete timestamp on the row	What a buyer sees after the seller deletes

Is message media access-controlled, or just an unlisted link?

If a locked video is served from a public URL nobody happens to have published, the paywall is an interface convention, and the first fan to copy a link has defeated it permanently.

The documentation is specific, and the answer is the right one. Message attachments live in their own storage bucket, described in the architecture dossier as private with ephemeral access, separate from both the public CDN bucket and the public avatar bucket. Private content is served through time-limited signed URLs generated per request, with a documented default expiry measured in minutes, and signed delivery is also described at the CDN layer for premium content. Uploads use randomized filenames to prevent path guessing, and attachment deletion is owner-only.

The security documentation treats this as something to verify rather than assume. Its upload and media checklist includes attempting direct access to restricted media object paths, attempting deletion of another user’s media identifier, and confirming sensitive media is not public before entitlement checks run. That is the correct posture: controls built, test plan assuming you will try to break them.

One honest caveat. A signed URL is valid for its lifetime no matter who holds it, so within that window the link is bearer-authenticated, not identity-authenticated. Shortening the window and keeping watermarking on are the documented mitigations. Neither stops a screen recorder, and no architecture does.

What happens to an unlocked message if the creator deletes it?

The documentation does not answer this, and it is worth stating plainly.

Three documented facts bracket the problem. The messages table uses a soft-delete timestamp, listed in the schema’s own soft-delete section under message retention, so a deleted row is not destroyed. The solution overview states that a fan who pays an unlock price receives access permanently. And the privacy documentation lists message privacy as an area where conversation deletion and scoped fetch controls “are required,” with verifying that message and media deletion aligns with policy listed as an audit check to perform.

Those are a retention mechanism, a product promise and a to-do item. They are not a rule. Nowhere does the documentation say what a buyer sees after the seller soft-deletes a message the buyer paid to unlock, or whether the attachment is still served. The compliance requirements do describe a hard-delete account flow with cascade cleanup of media, conversations and files, which suggests access ends at the account level, but that is an inference from a different flow.

Treat it as a decision you own. Three answers are defensible: the buyer keeps access, the buyer is refunded, or a purchased message cannot be deleted. Each changes your refund rate, support load and takedown handling. Pick one, write it into your terms, have it tested.

How is the automatic welcome message wired, and can it charge?

The automatic welcome DM is the highest-leverage inbox automation on a subscription platform, because it fires at the one moment a fan has just chosen to pay and is still looking at the screen. It is configured on the creator’s own user record rather than in a separate automation engine, which is why it can be set up before any conversation exists.

Three columns on the user table carry it: a boolean toggle defaulting to off, a text body, and a nullable price. That third one is the interesting column. The welcome message can be a paid message, so a creator can price the first thing a new subscriber ever receives.

A separate media_welcome_messages table holds the rich version, with a media type of image or video, a file path and its own price column. The media polymorphism table shows why it is modeled separately: a welcome asset attaches to the user, not to a message or a post. The product requirements list the auto-DM welcome video as a shipped requirement, and the subscription lifecycle notes that welcome-message features “may trigger if enabled by user settings,” which is correct conditional framing given the toggle defaults to off.

Two decisions follow. Pricing the welcome message is a conversion lever and a churn lever at once, so keep it configurable per creator rather than platform-wide. And because the toggle defaults to off, welcome automation is something creator onboarding has to teach.

Can a fan tip inside a conversation?

Yes, as a first-class endpoint rather than a repurposed one. The API exposes a dedicated send-tip route under the messages family. The message type enumeration includes a gift value alongside the media types, so a tip or gift exists as a message in the thread rather than a notification that scrolls away.

A tip attached to a message is a tip with context: the creator sees what it was for. The central ledger has distinct tip and gift transaction types, so that revenue stays separable from subscriptions and unlocks, and the daily per-creator rollup tracks tips as their own figure.

What the documentation does not describe is a per-conversation or per-day spend ceiling for a fan. There are documented minimum and maximum price guards at platform level for subscriptions and pay-per-view posts, and documented throttling on payment initiation as a recommended abuse control. There is no documented cap on how much one fan can tip into one thread in one evening. For chargeback exposure and for responsible-spending reasons, that is worth adding deliberately. It is an addition, not a configuration flag.

Is a send to many fans one broadcast, or many conversations?

Many conversations. This is the most important thing to understand about inbox load.

Bulk sending does exist. A mass-message table holds the campaign object with its content, an optional price, a sent count, a status and a scheduled timestamp; a separate table holds the scheduled-send queue; a mass-send API route is scoped to creators and managers. A named queue job does the work, documented on the messaging queue with a ten-minute service target, two retries and a dead-letter destination.

But the documented workflow is a fan-out, not a broadcast. The worker iterates recipients, and for each one writes an individual message row, a transaction row if the send is priced, and a notification. The campaign object is the instruction; the inbox gets one real message per fan.

Three consequences, all of them inbox consequences. Reply load scales with recipients, because every row sits in a thread a fan can answer and there is no documented one-to-many reply surface. Delivery is asynchronous and worker-bounded, so a creator who clicks send is scheduling work, not completing it, and your interface should say so. And a priced mass send writes one transaction per paying recipient, so one creator action can produce a burst of payment rows your reconciliation has to tolerate. Documented spam handling is throttle middleware plus creator-level limits plus admin settings: configure it rather than leave it at defaults.

What inbox tooling does a creator actually get?

Message templates are a creator-owned table with a title, body and category, and the documentation names five categories in use: welcome, PPV promotion, tip thanks, stream alert and general. That is a working taxonomy, not a placeholder, and it tells you what high-volume creators retype.

Conversation state is per participant rather than per thread, which is the correct design and easy to get wrong. The participant junction row carries its own role of admin, member or muted, its own last-seen timestamp as the read marker, and its own pinned flag, so two people in one conversation hold independent read and pin state. Pinning an individual message has its own API route.

Real-time behavior runs on a private broadcast channel scoped to the conversation identifier, carrying new-message and typing events, with notifications on a separate private user channel. Voice notes have dedicated upload endpoints for one-to-one and group threads alike, and group conversations get member add, remove and leave routes gated to group administrators. A restrictions table handles mute and block as a unique triple of actor, target and type, and a single allow-DM boolean governs whether a creator accepts direct messages at all. Admin moderation covers messages alongside posts, comments, reels and stories, with a flag queue, takedown reason codes and reporter identity protection. Manager accounts can hold a scoped permission including messages, so someone can work a creator’s inbox without that creator’s credentials.

Which parts of paid messaging are shipped, and which are configuration?

The distinction between a shipped feature, a configurable capability and a hardening recommendation is where readiness assessments go wrong. The platform’s feature catalogue uses three labels, and they are not synonyms. Direct messages, group chat, voice notes, templates, pinning, read receipts, typing indicators, search, scheduled sends and broadcast sends all carry the strongest label. Message rate limiting and message translation carry the middle label, with translation noted as AI-powered. Several adjacent capabilities elsewhere are marked not implemented outright. Flatten all three into one number and you lose exactly the information you needed.

Four specifics for the inbox. Real-time delivery is not first-party: it runs on a socket service, with a documented primary provider, a fallback and a self-hostable compatible option, plus separate push providers. Message translation and AI persona behavior depend on an integrations record storing a provider name, a model identifier and an API key, so the key and the account are yours and usage is billed to you rather than bundled. Age verification runs through named third-party integrations the operator wires up, not an in-house verification service. And payouts are a shipped queue with admin review, but the gateway relationships, fees and compliance behind them are yours to establish.

On security, two-factor authentication is shipped with an authenticator and OTP path, request throttling exists as application middleware, and transaction audit trails are shipped. But the enterprise readiness table marks the audit log for authentication events as partial: login sessions are tracked, admin action logging is configurable. And the developer security handbook’s own table of contents lists a chapter on rate limiting and abuse prevention that the delivered document does not contain. The guidance that does exist sits in the security assurance document as recommended controls per flow, including per-user throttling on conversation search and per-user upload caps. Recommended controls are a plan. Budget the work.

Separately, and not an engineering matter: age verification, consent records, payment-processor policy and takedown duties sit with you as the operator. The platform provides integration points and moderation queues, not the policy, and nothing in the documentation should be read as a certification.

What can you actually measure about a paid inbox?

Less than you will want. The per-creator daily rollup is a real table: profile views, follower and following deltas, subscription delta, daily earnings, daily tips and a message volume count. So you can answer how many messages a creator sent on a day and what they earned in total.

What the documented rollups cannot answer is the question that actually runs a paid inbox: what share of priced messages got unlocked. The per-post daily rollup includes an explicit PPV unlock counter; the per-creator rollup includes no message unlock counter, and message volume counts sends, not conversions. You can derive the rate by querying the message table for priced rows grouped by paid flag, which is fine on a young platform. At scale it is a table the documentation itself projects into the hundreds of millions of rows per year, with a maintenance job archiving old messages, so an ad-hoc aggregate over it is not a dashboard you want on a shared database.

The cheap fix is the right one: add unlock counters to the existing daily rollup, in the same batch process that already writes message volume. Do it before launch and creators can see whether their pricing works, which is the number that decides whether they keep using the inbox at all.

Founder Decision Signals

Build the priced DM first if your creators already sell one-off content by hand, in another inbox, at negotiated prices. The data model fits that behavior exactly and you are formalizing something that already converts.

Put the welcome message first if churn is concentrated in week one. It fires at the highest-intent moment you will get and costs one toggle plus a body of text.

Settle the entitlement question before any payment code ships if you plan to offer refunds, a purchase history view, or to operate where withdrawal rights apply.

Add spend controls before launch if your category attracts high-frequency tippers. Chargeback exposure accumulates quietly and there is no documented per-thread ceiling to lean on.

Budget the recommended security controls as line items if you are raising or facing review. “Recommended” in a security document means unbuilt, and a reviewer will read it that way too.

Common Paid-Messaging Mistakes to Avoid

Treating the inbox as a chat feature. Chat needs delivery and presence. A paid inbox needs an entitlement model, a ledger, a refund path and an audit trail. Teams that scope it as chat ship the first half and find the second half during their first dispute.

Promising permanent access without deciding what deletion does. The product narrative says permanent, the schema soft-deletes, and the security document calls the behavior a thing to verify. Until you decide, you have made a promise your system has not been told to keep.

Launching with no unlock-rate metric. Creators who cannot see whether a price worked will stop setting prices, and this is the cheapest thing here to fix.

How a Ready-Made Foundation Fits a Paid DM Inbox

The argument for starting from a built foundation is not that it saves you from thinking. This whole post is a list of things you still have to think about. The argument is that it moves the thinking to the right place.

From scratch, your first two months go into the parts identical on every creator platform: conversation containers, participant junctions, read markers, soft deletes, upload pipelines, signed delivery, queue workers, a transaction ledger, a moderation queue. None of that is where your product differs. On a deployed foundation that work already stands, and the two months go instead into the seven rows of the table above, the entitlement decision, the deletion policy, the spend ceiling and the unlock metric: the decisions that determine whether the inbox makes money.

That is how Miracuves works on these builds. We deploy the documented foundation, say which parts are shipped and which are integration paths you will fund, and treat the gaps named here as scoped work rather than surprises. You own the code and the infrastructure, you open your own provider accounts, and the compliance obligations stay with you as the operator. The commercial scope is on the FanCentro clone script hub, the wider platform engineering under our influencer platform solution, and the engagement mechanics that feed an inbox in our guide to creator platform fan engagement.

Final Thoughts

A paid DM inbox is two columns on one table and a dozen decisions nobody writes down. The columns are easy. The decisions separate a platform creators keep using from one they drift away from.

What is genuinely good here is how much of the hard infrastructure is already correct: private attachment storage with expiring access, a single ledger every payment routes through, per-participant conversation state, a real queue behind bulk sends, and a security test plan that assumes someone will attack the paywall. What is incomplete is narrow and nameable: the message entitlement record, the deletion rule, the per-thread spend ceiling, the unlock metric, and rate-limiting controls that exist as recommendations rather than code. Build those five into the plan, make the deletion decision in writing, and the inbox will earn more per fan than the feed ever will.

FAQs

<!– wp:rank-math/faq-block {"questions":[{"id":"faq-question-17613401","title":"Does a FanCentro clone script support pay-per-view direct messages out of the box?","content":"

Yes. The documented message table carries a nullable price column and a paid flag, and the documented message flow writes a transaction row when a message is priced. Confirm one thing with your build team: whether unlocking also writes a row to the separate pay-per-view entitlement table, because the schema lists posts, media and reels as the types that table covers and does not list messages.

“,”visible”:true},{“id”:”faq-question-17613402″,”title”:”Can creators send one paid message to all of their subscribers at once?”,”content”:”

They can trigger it with one action, but no shared broadcast object is created. A documented queue job iterates the recipient set and writes an individual message row for each fan, plus a transaction row for each one who pays. So a mass send produces as many real conversations as there are recipients, each repliable, and both reply volume and payment-row volume scale with audience size.

“,”visible”:true},{“id”:”faq-question-17613403″,”title”:”Is media inside a locked message properly protected, or just hidden?”,”content”:”

Properly protected, per the architecture documentation. Message attachments sit in a dedicated private bucket with ephemeral access, separate from the public CDN and avatar buckets, and are delivered through short-lived signed URLs with randomized filenames to prevent path guessing. The residual limitation is inherent to signed URLs: within the expiry window the link works for whoever holds it, so keep the window short and watermarking on.

“,”visible”:true},{“id”:”faq-question-17613404″,”title”:”What happens if a creator deletes a message a fan already paid to unlock?”,”content”:”

The documentation does not define this. The message table soft-deletes, so the row survives, and the solution overview says paid unlocks grant permanent access, but the privacy documentation treats message deletion behavior as something to verify against your own policy rather than a defined rule. Choose between buyer keeps access, buyer is refunded, or purchased messages cannot be deleted, then implement it and write it into your terms.

“,”visible”:true},{“id”:”faq-question-17613405″,”title”:”Are automatic welcome messages a shipped feature or an add-on?”,”content”:”

Shipped, and configured on the creator’s user record through a toggle, a message body and an optional price, with a separate table holding rich image or video welcome assets that carry their own price. The product requirements list the automatic welcome video to new subscribers as a requirement. Note that the toggle defaults to off, so welcome automation is something creator onboarding has to actively teach.

“,”visible”:true},{“id”:”faq-question-17613406″,”title”:”Can a fan tip on a specific message, and can we cap how much they spend?”,”content”:”

In-thread tipping runs on a dedicated send-tip API route, and the message type enumeration includes a gift value, so the tip lives in the conversation and lands in the central ledger under its own transaction type. Spend caps are different. Minimum and maximum price guards are documented for subscriptions and pay-per-view posts, but no per-conversation or per-day fan spending ceiling is documented. Treat that cap as scoped work.

“,”visible”:true},{“id”:”faq-question-17613407″,”title”:”Which messaging features depend on third-party accounts we have to pay for?”,”content”:”

Real-time delivery of new-message and typing events runs on a socket service, with a documented primary provider, a fallback and a self-hostable compatible option, plus separate push providers. Message translation and AI persona behavior read a provider name, model and API key from an integrations record, so the account and the usage bill are yours. Age verification runs through named external provider integrations. None is bundled.

“,”visible”:true},{“id”:”faq-question-17613408″,”title”:”Is message rate limiting and inbox audit logging already built?”,”content”:”

Partly. Request throttling exists as application middleware, two-factor authentication is shipped, and transaction audit trails are shipped. But the enterprise readiness table marks the audit log for authentication events as partial, with login sessions tracked and admin action logging described as configurable, and messaging rate limiting is labeled a supported capability with per-user limits rather than a default. Plan to implement the recommended controls as work.

“,”visible”:true}]} –>