Droppod — a web shop for your ARK: Survival Ascended cluster that delivers by itself

Vasile Jianu

New member
Ydd.pngour server gets a storefront on its own subdomain. Players buy in a browser, and it lands in their inventory in game automatically — on the character they've proved is theirs, whether or not you're online.

What you can sell

  • Items and resources — delivered stack by stack, 300× stone included
  • Creatures — spawned and handed over in a cryopod
  • Ranks — your Permissions groups, permanent or by the day, expired by the server itself
  • Shop points — credited straight to their ArkShop balance

Why it isn't another RCON shop

  • No RCON password anywhere. The plugin talks to the shop directly, and nothing the shop sends is ever run as a console command.
  • Never delivered twice. Every order is claimed by one server and logged durably. A crash mid-delivery stops and asks you rather than guessing.
  • It tells you when it can't. Bad blueprint path, a group your server doesn't have, an inventory that filled up — the order stops with the reason on it and a one-click retry, instead of quietly eating someone's money.
  • The plugin arrives pre-configured. Download it from your own admin with your token and endpoints already written in. Same folder onto every server in the cluster.

Money goes into your own Stripe account, not ours — we never hold it. Players buy tokens once and spend them across many purchases, which is what keeps 50-token items worth listing.

Free — 5% of token sales. Pro — £15/month, 0% fee. Nothing to pay until you're actually selling.

Setup walkthrough, including the bits that trip people up: https://droppod.gg/getting-started
Site: https://droppod.gg
 
YView attachment 1420our server gets a storefront on its own subdomain. Players buy in a browser, and it lands in their inventory in game automatically — on the character they've proved is theirs, whether or not you're online.

What you can sell

  • Items and resources — delivered stack by stack, 300× stone included
  • Creatures — spawned and handed over in a cryopod
  • Ranks — your Permissions groups, permanent or by the day, expired by the server itself
  • Shop points — credited straight to their ArkShop balance

Why it isn't another RCON shop

  • No RCON password anywhere. The plugin talks to the shop directly, and nothing the shop sends is ever run as a console command.
  • Never delivered twice. Every order is claimed by one server and logged durably. A crash mid-delivery stops and asks you rather than guessing.
  • It tells you when it can't. Bad blueprint path, a group your server doesn't have, an inventory that filled up — the order stops with the reason on it and a one-click retry, instead of quietly eating someone's money.
  • The plugin arrives pre-configured. Download it from your own admin with your token and endpoints already written in. Same folder onto every server in the cluster.

Money goes into your own Stripe account, not ours — we never hold it. Players buy tokens once and spend them across many purchases, which is what keeps 50-token items worth listing.

Free — 5% of token sales. Pro — £15/month, 0% fee. Nothing to pay until you're actually selling.

Setup walkthrough, including the bits that trip people up: https://droppod.gg/getting-started
Site: https://droppod.gg
This looks neat what advantages does this have compared to Tip4Server or Tebex? Also what type of security does this have to protect our data?
 
This looks neat what advantages does this have compared to Tip4Server or Tebex? Also what type of security does this have to protect our data?
Here is my honest take

On Tebex and Tip4Serv

They're both good, established products, and for a lot of servers they're the right answer. The differences worth knowing:

No RCON password. This is the big one for ARK. Most shop platforms deliver by opening a remote console and running commands, which means handing over server-admin access that then sits in someone else's database. Droppod never opens a console. Deliveries go to a plugin as typed fields — a
blueprint path, a quantity, a quality — and the plugin makes the native game call itself. There's no admin password to give up, so there's nothing to leak.

You find out whether it actually worked. A console command tells you nothing about its own outcome. The plugin reports back per order line: delivered, failed with a reason, or part-delivered with the exact quantity that landed. Which server handed it over, when, and how many attempts it took
are all recorded.

It won't deliver twice. Each line is leased to one server while it's being worked on, so two servers in a cluster can't both hand over the same purchase. If the plugin crashes mid-delivery and genuinely can't say whether the items arrived, the order stops and asks you — it never guesses and
retries, because the failure mode of guessing is giving someone a second copy.

Ranks are read back, not assumed. A timed rank expiring fires no event anywhere. Droppod re-reads what groups the server actually holds every 30 seconds, so what a player sees is what the server says now, not what was bought three weeks ago.

A live player map. Where everyone is standing, drawn on the right map per server across a cluster. I don't believe either of the others does this.

Money goes to your own Stripe account. Charges are made directly on your connected account with a platform fee on top — Droppod never holds your revenue.

Where they're stronger, honestly: Tebex is merchant of record, which means they take on VAT and sales-tax compliance for you globally. With Droppod you're the merchant, so that's yours to handle — for some sellers that alone is worth their fee. They also have years of track record, more
payment methods and more games. Droppod is new, and you should weigh that.

On security

- Every shop gets its own database. Not a shared table with a filter on it — physical separation, so a query bug can't cross shops.
- No RCON credentials exist to steal, per the above.
- The plugin authenticates with a revocable, scoped token, not a shared key. It can only reach plugin endpoints, and you can revoke it without touching anything else.
- Card details never touch the app. Payments go through Stripe; there is no card field anywhere in the codebase.
- Two-factor auth and passkeys are available on accounts, with rate limiting on login, 2FA and passkey attempts.
- Your Discord client secret is encrypted at rest. It's never sent back to the browser — the settings page only tells you whether one is stored.
- Logs record field names, never values, specifically so player Discord and EOS IDs don't end up in a log file.
- Player positions keep only the latest, with no movement history — there's no record of where anyone has ever been to breach. The map is staff-only until you deliberately open it.


Im also a veteran ark player and server owner so I know what other admins owners want so always looking to add tools that benefit both players and admins like this one today :DScreenshot 2026-08-04 at 19.01.43.png
 
Here is my honest take

On Tebex and Tip4Serv

They're both good, established products, and for a lot of servers they're the right answer. The differences worth knowing:

No RCON password. This is the big one for ARK. Most shop platforms deliver by opening a remote console and running commands, which means handing over server-admin access that then sits in someone else's database. Droppod never opens a console. Deliveries go to a plugin as typed fields — a
blueprint path, a quantity, a quality — and the plugin makes the native game call itself. There's no admin password to give up, so there's nothing to leak.

You find out whether it actually worked. A console command tells you nothing about its own outcome. The plugin reports back per order line: delivered, failed with a reason, or part-delivered with the exact quantity that landed. Which server handed it over, when, and how many attempts it took
are all recorded.

It won't deliver twice. Each line is leased to one server while it's being worked on, so two servers in a cluster can't both hand over the same purchase. If the plugin crashes mid-delivery and genuinely can't say whether the items arrived, the order stops and asks you — it never guesses and
retries, because the failure mode of guessing is giving someone a second copy.

Ranks are read back, not assumed. A timed rank expiring fires no event anywhere. Droppod re-reads what groups the server actually holds every 30 seconds, so what a player sees is what the server says now, not what was bought three weeks ago.

A live player map. Where everyone is standing, drawn on the right map per server across a cluster. I don't believe either of the others does this.

Money goes to your own Stripe account. Charges are made directly on your connected account with a platform fee on top — Droppod never holds your revenue.

Where they're stronger, honestly: Tebex is merchant of record, which means they take on VAT and sales-tax compliance for you globally. With Droppod you're the merchant, so that's yours to handle — for some sellers that alone is worth their fee. They also have years of track record, more
payment methods and more games. Droppod is new, and you should weigh that.

On security

- Every shop gets its own database. Not a shared table with a filter on it — physical separation, so a query bug can't cross shops.
- No RCON credentials exist to steal, per the above.
- The plugin authenticates with a revocable, scoped token, not a shared key. It can only reach plugin endpoints, and you can revoke it without touching anything else.
- Card details never touch the app. Payments go through Stripe; there is no card field anywhere in the codebase.
- Two-factor auth and passkeys are available on accounts, with rate limiting on login, 2FA and passkey attempts.
- Your Discord client secret is encrypted at rest. It's never sent back to the browser — the settings page only tells you whether one is stored.
- Logs record field names, never values, specifically so player Discord and EOS IDs don't end up in a log file.
- Player positions keep only the latest, with no movement history — there's no record of where anyone has ever been to breach. The map is staff-only until you deliberately open it.


Im also a veteran ark player and server owner so I know what other admins owners want so always looking to add tools that benefit both players and admins like this one today :DView attachment 1426
Doesn't Tip4Server and Tebex both have plugin support or are they strictly RCON? Is the website vibe coded at all I see alot of elements like over use of dashes and circle online indictors and such that look little bit vibe coded. Do you have HASHing setup and HMAC security, What GDPR related user information is stored? Is cookie consent setup? How did you setup the Stripe is it a platform/marketplace Stripe account that generates stripe stores under your marketplace account like Tip4Server does or is it Stripe oAuth token based for each user? What type of customer data do you store in the database?

What's difference about your pricing compared to Tip4Server I see you do same 5% fee as them? It does look interesting but with website having elements that look vibe coded gives concerns about security if I were to use it over Tip4Server.
 
Doesn't Tip4Server and Tebex both have plugin support or are they strictly RCON? Is the website vibe coded at all I see alot of elements like over use of dashes and circle online indictors and such that look little bit vibe coded. Do you have HASHing setup and HMAC security, What GDPR related user information is stored? Is cookie consent setup? How did you setup the Stripe is it a platform/marketplace Stripe account that generates stripe stores under your marketplace account like Tip4Server does or is it Stripe oAuth token based for each user? What type of customer data do you store in the database?

What's difference about your pricing compared to Tip4Server I see you do same 5% fee as them? It does look interesting but with website having elements that look vibe coded gives concerns about security if I were to use it over Tip4Server.


On plugins vs RCON — fair challenge, and I should be precise. Both offer plugin integrations; I'm not going to characterise their internals, and if I implied they're RCON-only, that was sloppy of me. The difference I'd actually point at isn't plugin-vs-RCON, it's what comes back. Droppod
never opens a console, so there's no admin password to hand over — but more usefully, every order line records what actually happened: delivered, failed with a reason, or part-delivered with the exact quantity that landed, which server did it, and how many attempts it took. Lines are leased
to one server at a time so a cluster can't double-deliver, and if the plugin crashes mid-delivery and genuinely can't say whether the items arrived, the order stops and asks you rather than guessing. Compare that against what the others report back — that's the comparison worth making.

Is it AI-assisted? Droppod, yes — substantially, and I'm not going to pretend otherwise, all software is AI driven nowadays so lets stop living in the past and embrace the future. You're right that some surface details read that way.

For my track record server forge.cx is not. I wrote that by hand, years before any of this tooling existed, and it's been running large ASA clusters for people ever since. I mention it because it's why I can review what I ship rather than just accept it — I know what this infrastructure does when it breaks, because
I've been on the wrong end of it.

I'd push back on one thing though: em-dashes and status dots are stylistic, and they tell you nothing about whether the auth model is sound. Judge that directly instead:

- 417 automated tests, covering the delivery state machine, tenant isolation and the authorization paths specifically.
- PHPStan level 7 across the application.
- Ask me how any of it works — how a cluster can't deliver the same purchase twice, how the Stripe fee is applied, what a plugin token can and can't reach — and I'll explain it precisely rather than in marketing terms.

Better still, don't take my word for it. The Free plan costs nothing until you sell something: set up a shop, point a test server at it, and try to make it deliver twice, or leak between shops. That'll tell you more than anything I can say.

Hashing and HMAC. Passwords are bcrypt. Plugin API tokens are hashed at rest and ability-scoped, so a plugin token can only reach plugin endpoints and is revocable on its own without touching anything else. Stripe webhooks are signature-verified with a per-shop secret, and every event ID is
claimed once so a replayed webhook is a no-op. Two-factor (TOTP with recovery codes) and passkeys are available, with rate limiting on login, 2FA and passkey attempts.

Straight answer on the rest: the plugin API is bearer-token over TLS, not HMAC request signing. The token identifies the shop; TLS provides integrity. Request signing would add defence against a compromised TLS path, and it's a reasonable thing to want — it isn't there today.

Stripe. Standard Connect accounts with direct charges. You get a real Stripe account with your own dashboard, you can connect one you already have, and you keep the customer relationship. Charges are made on your account with an application fee on top — your money lands in your Stripe
balance and Droppod never holds it. It is deliberately not a marketplace model where sub-accounts live under my platform account. If Tip4Serv works the way you describe, that's a genuine structural difference: with theirs, worth asking who is merchant of record and whose balance the money
sits in before payout.

Data stored. Per shop, in that shop's own separate database:

- Account — name, email, bcrypt password hash, optional Discord ID, EOS ID once a character is linked, token balance and ledger.
- Game-side — character name, tribe name and tribe ID, Permissions groups, and the latest position only. No movement history, ever.
- Commerce — orders and line items, Stripe customer and session IDs. No card data touches the app at all.
- Sessions — standard Laravel sessions, which include IP and user agent.

Application logs record field names, never values, specifically so Discord and EOS IDs stay out of log files.

GDPR and cookies. There's a published privacy policy, terms and refund policy. Consent for immediate delivery of digital content is recorded per purchase with a timestamp, so the 14-day cancellation position is documented rather than assumed. Shops are database-isolated, and the player map
defaults to staff-only.

On cookies specifically: the app sets only essential cookies — the session cookie and the CSRF token. There is no Google Analytics, no tag manager, no pixel, no third-party tracking of any kind. You were right that there was no consent banner though, and I'm building one today: recorded with
a timestamp, and changeable afterwards rather than a one-time click you can never revisit.

Pricing. Free is 5%, the same as theirs — but there's a Pro plan at £15/month that takes 0%. Above roughly £300/month in sales the flat fee works out cheaper, and it's a fixed cost rather than a tax on growth. If you're doing volume, that's the difference.
 
On plugins vs RCON — fair challenge, and I should be precise. Both offer plugin integrations; I'm not going to characterise their internals, and if I implied they're RCON-only, that was sloppy of me. The difference I'd actually point at isn't plugin-vs-RCON, it's what comes back. Droppod
never opens a console, so there's no admin password to hand over — but more usefully, every order line records what actually happened: delivered, failed with a reason, or part-delivered with the exact quantity that landed, which server did it, and how many attempts it took. Lines are leased
to one server at a time so a cluster can't double-deliver, and if the plugin crashes mid-delivery and genuinely can't say whether the items arrived, the order stops and asks you rather than guessing. Compare that against what the others report back — that's the comparison worth making.

Is it AI-assisted? Droppod, yes — substantially, and I'm not going to pretend otherwise, all software is AI driven nowadays so lets stop living in the past and embrace the future. You're right that some surface details read that way.

For my track record server forge.cx is not. I wrote that by hand, years before any of this tooling existed, and it's been running large ASA clusters for people ever since. I mention it because it's why I can review what I ship rather than just accept it — I know what this infrastructure does when it breaks, because
I've been on the wrong end of it.

I'd push back on one thing though: em-dashes and status dots are stylistic, and they tell you nothing about whether the auth model is sound. Judge that directly instead:

- 417 automated tests, covering the delivery state machine, tenant isolation and the authorization paths specifically.
- PHPStan level 7 across the application.
- Ask me how any of it works — how a cluster can't deliver the same purchase twice, how the Stripe fee is applied, what a plugin token can and can't reach — and I'll explain it precisely rather than in marketing terms.

Better still, don't take my word for it. The Free plan costs nothing until you sell something: set up a shop, point a test server at it, and try to make it deliver twice, or leak between shops. That'll tell you more than anything I can say.

Hashing and HMAC. Passwords are bcrypt. Plugin API tokens are hashed at rest and ability-scoped, so a plugin token can only reach plugin endpoints and is revocable on its own without touching anything else. Stripe webhooks are signature-verified with a per-shop secret, and every event ID is
claimed once so a replayed webhook is a no-op. Two-factor (TOTP with recovery codes) and passkeys are available, with rate limiting on login, 2FA and passkey attempts.

Straight answer on the rest: the plugin API is bearer-token over TLS, not HMAC request signing. The token identifies the shop; TLS provides integrity. Request signing would add defence against a compromised TLS path, and it's a reasonable thing to want — it isn't there today.

Stripe. Standard Connect accounts with direct charges. You get a real Stripe account with your own dashboard, you can connect one you already have, and you keep the customer relationship. Charges are made on your account with an application fee on top — your money lands in your Stripe
balance and Droppod never holds it. It is deliberately not a marketplace model where sub-accounts live under my platform account. If Tip4Serv works the way you describe, that's a genuine structural difference: with theirs, worth asking who is merchant of record and whose balance the money
sits in before payout.

Data stored. Per shop, in that shop's own separate database:

- Account — name, email, bcrypt password hash, optional Discord ID, EOS ID once a character is linked, token balance and ledger.
- Game-side — character name, tribe name and tribe ID, Permissions groups, and the latest position only. No movement history, ever.
- Commerce — orders and line items, Stripe customer and session IDs. No card data touches the app at all.
- Sessions — standard Laravel sessions, which include IP and user agent.

Application logs record field names, never values, specifically so Discord and EOS IDs stay out of log files.

GDPR and cookies. There's a published privacy policy, terms and refund policy. Consent for immediate delivery of digital content is recorded per purchase with a timestamp, so the 14-day cancellation position is documented rather than assumed. Shops are database-isolated, and the player map
defaults to staff-only.

On cookies specifically: the app sets only essential cookies — the session cookie and the CSRF token. There is no Google Analytics, no tag manager, no pixel, no third-party tracking of any kind. You were right that there was no consent banner though, and I'm building one today: recorded with
a timestamp, and changeable afterwards rather than a one-time click you can never revisit.

Pricing. Free is 5%, the same as theirs — but there's a Pro plan at £15/month that takes 0%. Above roughly £300/month in sales the flat fee works out cheaper, and it's a fixed cost rather than a tax on growth. If you're doing volume, that's the difference.
Great information thank you for that. Have you tested the REST API against Fiddler? It looks solid and the idea is great only concern that pops into head is how good is the security if used AI on the site development. I know if you use Fiddler in the right manor you can bruteforce alot of sites that link REST-API bearer so would that be a concern if have hundreds of customers data. I've actually done that myself to a few websites to see how good their REST API was and nearly all the vibe coded sites I Fiddler I was able to get into owner's admin dashboard via DiscordID bruteforce, I would lock alot of that down under Cloudflare workers and trust access and IP restrict the databases and research into Fiddler and test it yourself to rule that out.
 
Great information thank you for that. Have you tested the REST API against Fiddler? It looks solid and the idea is great only concern that pops into head is how good is the security if used AI on the site development. I know if you use Fiddler in the right manor you can bruteforce alot of sites that link REST-API bearer so would that be a concern if have hundreds of customers data. I've actually done that myself to a few websites to see how good their REST API was and nearly all the vibe coded sites I Fiddler I was able to get into owner's admin dashboard via DiscordID bruteforce, I would lock alot of that down under Cloudflare workers and trust access and IP restrict the databases and research into Fiddler and test it yourself to rule that out.

Good question, and a fair test to run.

Auth is Laravel Sanctum, not something I wrote. It's Laravel's own first-party token package, used by a very large number of production apps and audited by far more eyes than mine. Tokens are 40 characters of cryptographic randomness, stored hashed — a database dump doesn't yield usable
tokens — and each is scoped to an ability, so the plugin's token can only reach plugin endpoints.

On the specific attack you describe: a plugin bearer token cannot reach an admin dashboard here at all. They're different guards. The API is stateless token auth; the admin is session auth plus a separate is_admin check in its own middleware, because shop members and the owner share a users
table and being signed in was never sufficient. There's no token that escalates into that.

A Discord ID is not a credential. You can't present one and be authenticated. The only place one is trusted is inside Discord's own verified OAuth callback, and linking a character to an account grants exactly that — a linked character. It carries no admin rights.

I also build against Laravel Boost, which enforces framework guidelines written by Laravel's own maintainers, so the conventions being followed aren't ones I invented.

Your Cloudflare and IP-restriction points are well taken and worth doing regardless
 
Good question, and a fair test to run.

Auth is Laravel Sanctum, not something I wrote. It's Laravel's own first-party token package, used by a very large number of production apps and audited by far more eyes than mine. Tokens are 40 characters of cryptographic randomness, stored hashed — a database dump doesn't yield usable
tokens — and each is scoped to an ability, so the plugin's token can only reach plugin endpoints.

On the specific attack you describe: a plugin bearer token cannot reach an admin dashboard here at all. They're different guards. The API is stateless token auth; the admin is session auth plus a separate is_admin check in its own middleware, because shop members and the owner share a users
table and being signed in was never sufficient. There's no token that escalates into that.

A Discord ID is not a credential. You can't present one and be authenticated. The only place one is trusted is inside Discord's own verified OAuth callback, and linking a character to an account grants exactly that — a linked character. It carries no admin rights.

I also build against Laravel Boost, which enforces framework guidelines written by Laravel's own maintainers, so the conventions being followed aren't ones I invented.

Your Cloudflare and IP-restriction points are well taken and worth doing regardless

It costs you nothing really to try it out , you can alter users tokens manually if you want a completely free run so no one needs to buy anything with real money , can "sell" silly stuff at low prices just to test stuff out
 
It costs you nothing really to try it out , you can alter users tokens manually if you want a completely free run so no one needs to buy anything with real money , can "sell" silly stuff at low prices just to test stuff out

Good question, and a fair test to run.

Auth is Laravel Sanctum, not something I wrote. It's Laravel's own first-party token package, used by a very large number of production apps and audited by far more eyes than mine. Tokens are 40 characters of cryptographic randomness, stored hashed — a database dump doesn't yield usable
tokens — and each is scoped to an ability, so the plugin's token can only reach plugin endpoints.

On the specific attack you describe: a plugin bearer token cannot reach an admin dashboard here at all. They're different guards. The API is stateless token auth; the admin is session auth plus a separate is_admin check in its own middleware, because shop members and the owner share a users
table and being signed in was never sufficient. There's no token that escalates into that.

A Discord ID is not a credential. You can't present one and be authenticated. The only place one is trusted is inside Discord's own verified OAuth callback, and linking a character to an account grants exactly that — a linked character. It carries no admin rights.

I also build against Laravel Boost, which enforces framework guidelines written by Laravel's own maintainers, so the conventions being followed aren't ones I invented.

Your Cloudflare and IP-restriction points are well taken and worth doing regardless
Automated server stat cards with nothing for you to configure Screenshot 2026-08-04 at 21.31.51.png:D
This is starting to be more than a shop lol
 
Back
Top