Can the same key be sold twice?
No. A paid order takes one unused key from the pool. A re-send repeats that same key. It does not mint a new one.
Upload a pool of unused license keys. Each paid Discord order takes one key and sends it by DM. Cartcord takes 0% of the sale.
To sell license keys on Discord, upload legitimate unused inventory, publish the supported software and activation terms, and deliver one assigned key only after confirmed payment. Key delivery and software enforcement are separate. Developers can opt into Cartcord's signed verification API with device limits and revocation, but their application must validate the response and implement a sensible recovery policy for legitimate customers.
Invite the bot
Open the dashboard with Manage Server.
Publish the product
Review payment eligibility and configure one unused key from your uploaded pool.
Buyers use /buy
After payment verification, configured delivery is attempted.
Choose by the actual product, audience and services you need. Cartcord's plans are Free $0, Basic $29.99, Pro $59.99 and Enterprise $129.99 per month. Cartcord charges no sales commission; PayPal processing and other merchant costs remain separate. A marketplace may provide discovery, billing, hosting or tax services that a flat Discord-store plan does not.
Interactive example. This preview does not create an order or charge a payment.
Members open the storefront, choose a product, and start checkout.
Specify the exact application, edition, operating systems and supported versions. A license for your desktop utility is different from a third-party account, a hosted subscription or a trial token. Sell only keys you created or are authorized to distribute. Explain whether activation requires an internet connection, whether the program continues working offline, and which functions stop when the license is revoked or expires.
Describe the device policy in buyer language. Two activations may mean two installations, two computers or two concurrent sessions; those are not interchangeable. Cartcord's optional device limit concerns the device identifiers submitted by your integration. The developer remains responsible for how those identifiers are generated and checked. Avoid collecting raw hardware details you do not need, and publish the relevant privacy information.
Use cryptographically random values or an existing trusted licensing system rather than sequential keys that a customer could guess. Check for duplicates before upload and keep the unissued pool private. A public preview, documentation screenshot or CSV attached to a support message can expose sellable inventory. The key generator tool can help create a pool, but creating random values does not by itself enforce a license inside software.
A paid key order receives an assigned inventory entry. Re-sending that order should repeat its assignment rather than consume another key. Test the empty-pool condition and replenish inventory before a launch. Keep your own inventory and order exports organized enough to investigate a mismatch without publishing keys in a Discord channel. Treat a leaked key as a revocation and replacement decision, not merely a display problem.
Enable license verification for the saved key product and choose the allowed devices per key. Your application sends the product identifier, license value, device identifier and a fresh nonce to the verification endpoint. The response includes a short-lived signed payload. Pin the trusted public key and verify the exact signed bytes, signature algorithm, issuer, product, key fingerprint, device binding, nonce and expiry before accepting it.
Do not trust a JSON field merely because it says valid. A proxy, a modified client or a response from another product could otherwise bypass the intended check. Keep the implementation guide with your application source, review key rotation before updating the pinned key, and never place a private signing credential in a browser or downloadable client. Cartcord's signing key stays server-side; the verifier needs the public key only.
A device identifier can change after a reinstall, a virtual-machine rebuild or a hardware replacement. Define how a customer requests a reset and what evidence support needs. The seller settings expose masked key records and device-reset controls so an administrator can release an activation deliberately. Resetting device records and undoing a revocation are different operations; a reset does not make a revoked key valid again.
Choose an outage policy consciously. A five-minute signed response has a limited lifetime, so your program must not silently treat an old response as permanent permission. At the same time, abruptly deleting customer work when the network fails is a poor recovery design. You can separate editing, saving and restricted premium actions according to the application's needs. Explain those choices before sale and test them without a network.
Only issued keys attached to eligible paid orders can activate through this API; unused stock is not a free trial. Full refunds revoke the corresponding keys. Describe what happens to access when you approve a refund, and verify that your application checks revocation at the intended intervals. Offline clients cannot receive a new revocation decision until they communicate again, which limits any immediate-revocation promise.
For a dispute, export the safe order evidence and review the payment and delivery timeline. A recorded key delivery does not prove that the customer installed or used the program. Preserve the listing terms and software release details needed to understand the purchase, and avoid sending an entire key pool to a payment provider. Build your support process around one order and one assigned key at a time.
Start from a hidden product and review it as a buyer: name, current price, included deliverables, dependencies, access duration, license and support contact. Connect the seller payment account for the intended store and verify that the selected product can be published. Use a genuine preview of your work. Remove test data, private credentials and unlicensed material before adding the delivery destination.
Run an authorized checkout test with an identity that represents a buyer, then inspect both the payment result and fulfillment result. A browser return page is not evidence of a captured payment by itself. Exercise purchase recovery and a delivery retry. Before announcing the product, keep a record of the terms, the version being sold and the recovery instructions your staff will give a customer.
Manual ticket selling can suit occasional custom work, but staff must reconcile each payment and fulfill each promise. A percentage marketplace may include discovery, billing, tax or hosting services you would otherwise operate. Cartcord's flat server plan and direct seller PayPal checkout serve a different workflow. Calculate the cost of the features you actually need instead of treating every percentage or subscription as interchangeable.
Include payment processing, currency conversion, hosting, refunds and support time in the comparison. Cartcord taking zero sales commission does not remove those costs or make Cartcord the merchant of record. Check the current plan's limits and provider eligibility for your particular product. Choose the route that meets the buyer's delivery and recovery needs at the volume you can realistically support.
| Responsibility | Manual ticket workflow | Cartcord released workflow |
|---|---|---|
| Payment confirmation | Staff reconcile the correct merchant transaction | Provider confirmation is checked before configured delivery |
| Fulfillment | Staff send the resource or complete the promised service | Configured file, link, key or role delivery is attempted; manual work still needs staff |
| Recovery | Staff locate the purchase and determine what was delivered | Original-account purchase recovery and recorded delivery results help investigate failures |
| Cost | Account for processor charges, tools and staff time | Account for the store plan, processor charges, hosting and support |
Enter your actual fees. These are editable USD scenarios, not provider quotes. Include processor charges in both scenarios. Compare equivalent services and permitted products; required platform checkout still applies.
Enter every fee, including zero where applicable. Use non-negative amounts, whole orders and percentages up to 100.
Taxes, refunds, disputes, conversion, payout and support costs need separate review. Cartcord sales commission is 0%; the store plan and processor costs remain.
No. A paid order takes one unused key from the pool. A re-send repeats that same key. It does not mint a new one.
Publish guard warns you before the product goes live, and an empty pool stops a new sale from promising a key you do not have.
On PayPal, into your account, after they run /buy or open the public store.
No. Cartcord never sits between the buyer and your PayPal.
Free is 3 products and 3 orders. Basic is 25 products and 100 orders. Pro adds coupons, themes, and docs at 150 products and 1,000 orders.