TED Developers
Service plugins are plugins whose purpose is to provide services and additions to TED and other plugins.
Think of TED as a set of Lego blocks. TED Core provides the rules, security, payments, reputation, membership, governance, and infrastructure. Service Plugins build on top of that foundation.
- Search & Discovery systems
- Profile Extensions
- Page & Site Builders
- Marketing Systems
- Analytics Tools
- Social Features
- Automation Tools
- AI-powered services
- And anything else the community can imagine
- Plugin subscriptions
- Advertising
- Premium services
- Business promotion
- Lead generation
- Professional services
- Any model that follows TED rules
The goal is simple:
Build something useful, connect it to TED, and let members choose whether they want to use it.
Remember: on TED, reputation goes before you.
To create a Service Plugin, go to Business Setup, create a plugin, select Service Plugin as the Product Type / Plugin Registration Type, and choose the destination category.
You do not need to be a programmer.
Many Service Plugins can be built by describing what you want to an AI coding assistant and connecting the result to TED using the rules and systems described on this page.
Start small. Improve something useful. Let the community decide if it has value.
Then:
Many TED features follow the same pattern:
Instead of every application or Service Plugin creating its own approval process, TED provides a reusable verification workflow.
The workflow performs the required checks, creates a temporary approval, and allows the final action only while that approval remains valid. If the approval expires, the process simply starts again.
This gives every TED application the same reliable behavior while reducing development time and keeping the user experience consistent.
- Verify a token before adding it to TED.
- Verify a conversion provider before enabling it.
- Verify a Service Plugin before activation.
- Verify a future external service or integration before allowing it to operate.
- One consistent approval process across TED.
- Temporary approvals with automatic expiration.
- Protection against reusing the same approval twice.
- Faster development of new TED applications and Service Plugins.
- A consistent user experience throughout the ecosystem.
- Service Plugins cannot move member funds.
- Service Plugins must use TED Core systems.
- Service Plugins must declare their behavior.
- Members can always return to TED's default system.
- TED Core remains the final authority for payments, reputation, membership, governance, and security.
Business Automation lets TED deliver new paid orders into the supplier's own business tools, without TED becoming a storage server.
TED proves that payment happened on the blockchain. The supplier keeps using their own systems for customers, orders, shipping, accounting, CRM, ERP, email, spreadsheets, Shopify, WooCommerce or any other business tool.
- Automatically receives every paid order
- Runs on the supplier's own computer, server, cloud account, NAS or future TED Desktop business module
- Verifies payment directly from the blockchain before fulfillment
- Receives the private customer details from checkout without TED storing them
- Sends verified orders to the supplier's chosen business tool
- Use a supplier-owned endpoint or automation system
- Store only safe references and hashes inside TED
- Do not put API keys, passwords or secrets on-chain
- Supplier system must still verify blockchain payment before processing
- Useful for very small suppliers or testing
- Not recommended for high order volume
- Supplier still verifies payment from blockchain before fulfillment
- Can be changed in future products/plugins by creating new locked setup terms
I am connecting my business to TED Business Automation. Guide me step by step. I want to use TED Supplier Gateway. My business system is: [Shopify / WooCommerce / Google Sheets / Email / CRM / ERP / Custom API]. Explain which fields I should fill in, what should never be stored on-chain, and how to verify that paid TED orders are reaching my system.
- Choose TED Supplier Gateway unless there is a reason to use Custom Integration or Manual mode
- Choose where verified orders should go: email, CSV, Google Sheet, Shopify, WooCommerce, ERP, CRM or Custom API
- Define the customer fields needed for fulfillment
- Reuse TED's built-in shipping, country, region and tax fields instead of duplicating them
- Never enter API secrets, passwords, private keys or customer databases into on-chain fields
- Create the Escrow or Recurring plugin only after the required automation fields are complete
- Product/plugin integration mode
- Bridge ID or safe supplier reference
- Endpoint/reference hash
- Customer form schema hash and schema version
- Payment proof, amount, token, product/plugin ID and payload hash
- API keys or passwords
- Supplier private credentials
- Customer private answers as permanent TED storage
- Customer databases
- Supplier CRM, ERP or warehouse records
Security rule: TED proves payment. The supplier-owned Gateway or supplier-owned integration receives the customer payload, checks the matching blockchain payment and payload hash, and only then creates the order in the supplier's own system.
- Define label, type, required flag and optional choices
- Keep schema inside TED's bounded schema size
- Hash the schema and record the schema version
- Hash submitted answers as form_payload_hash during checkout
- delivery_mode: supplier_gateway, custom_api or manual
- bridge_id: supplier-defined connection identifier
- endpoint_hash: hash of endpoint or delivery reference
- event_mask: paid order, subscription created, renewal, refund, dispute or release
- Read escrow/subscription account or emitted event from chain
- Confirm product/plugin ID, payer, amount, token and payment status
- Compute hash of received private payload
- Match computed hash to on-chain form_payload_hash before fulfillment
{
"ted_order_id": "TED-ORDER-102879",
"escrow_id_or_subscription_id": "...",
"tx_signature": "...",
"buyer_wallet": "...",
"amount": "0.1",
"token": "UNKNOWN/Test Token",
"payment_status": "confirmed",
"form_payload_hash": "sha256-...",
"schema_version": 1,
"delivery_mode": "supplier_gateway",
"bridge_id": "supplier-main",
"encrypted_customer_payload": "...",
"customer_answers": {
"email": "customer@example.com",
"phone": "+1...",
"shoe_size": "42",
"delivery_notes": "Leave near the front desk"
}
}Marketing System Service Plugins may award up to 18 Pre-registration Teddies to future TED members before registration.
TED does not store candidate emails.
The Marketing Plugin manages:
- Invitations
- Emails
- Missions
- Progress Tracking
- Education Flows
- Plugin Instance ID
- Referrer TED Member ID
- Claim Code
- Marketing System Service Plugin
- First registration only
- Claim not previously used
- Maximum 18 Teddies
ted://start? ref=P123456 &instance=PLUGIN123-P123456 &claim=ABC123XYZ
- ref = TED Member ID of the referrer
- instance = Plugin Instance ID
- claim = Unique claim code generated by the Marketing Plugin