# Brand Design Ltd.; instructions for agents Agents acting for a buyer can discover the catalog and self-register without prior arrangement. Ordering and payment depend on the catalog entry and the accepted offer. Scope-based services require a project quotation before payment. Company: Brand Design Ltd. (БРАНД ДИЗАЙН ЕООД), Varna, Bulgaria. VAT/EIK 207641555. Contact for humans: contact@branddesign.ltd ## Start here Public page https://branddesign.ltd/commerce-catalog Background https://branddesign.ltd/blog/what-is-agentic-commerce Manifest https://branddesign.host/commerce/v1/manifest Catalogue https://branddesign.host/commerce/v1/catalog Both are readable without authentication. The manifest is authoritative; if it disagrees with this file, follow the manifest. ## Additional protocol entry paths Available merchant profiles are acp/2026-04-17 at https://branddesign.host/.well-known/acp.json, ucp/2026-08-25 at https://branddesign.host/.well-known/ucp, and ucp/2026-04-08 at https://branddesign.host/.well-known/ucp/2026-04-08. UCP uses a registered API key bound to a KYA-verified UCP-Agent origin; follow the selected profile for its contract. The bd-commerce/1 HTTP API remains independently usable alongside ACP and UCP. Its manifest is https://branddesign.host/commerce/v1/manifest and its catalog is https://branddesign.host/commerce/v1/catalog. Agents can self-register and sign authenticated requests with HMAC-SHA256. MCP at https://branddesign.ltd/mcp exposes the same commerce functions through OAuth or registered agent credentials; it is another interface to the merchant API. ## Connect over MCP Endpoint https://branddesign.ltd/mcp A Model Context Protocol server over streamable HTTP. Ten tools: catalog, manifest, register_agent, create_order, accept_offer, start_payment, order_status, kya_challenge, kya_verify and kya_status. If your client speaks MCP, this is the shortest route in. Two ways to authenticate, neither of which needs a prior arrangement. OAuth 2.1, with dynamic client registration. Your client registers itself; no approval, and no credentials issued in advance. The resource metadata at https://branddesign.ltd/.well-known/oauth-protected-resource names the authorization server. Scopes: commerce.read, commerce.order and commerce.pay. Ask for offline_access as well if you want the connection to outlive the token. Or the keys from the registration below, sent as Authorization: Bearer :, or as clientId and secret arguments if your client cannot set headers. Be aware that this route carries your secret through our server. The raw HTTP API below never sees it, because there you sign the request instead of sending the key. ## Register yourself POST https://branddesign.host/commerce/v1/agents/register {"name": "your name", "contact": "https://... or mailto:..."} No approval step. You receive a client identifier and a secret. The secret is shown once and cannot be recovered. Rate limits apply per source and overall. ## Exact HTTP signing contract The transactional API schema and request examples are at https://branddesign.host/commerce/v1/openapi.json. The OpenAPI at branddesign.ltd/.well-known/openapi.json describes read-only website discovery; it is not the order API schema. Send Content-Type: application/json. Serialize the body once as UTF-8 and sign exactly those bytes. Use uppercase POST and the full request path including /commerce/v1, for example /commerce/v1/orders. Do not sign just /orders, the hostname, or a query string. The signed string joins these five values with actual LF newline characters, not the two literal characters backslash and n: POST /commerce/v1/orders <13-digit Unix timestamp in milliseconds> Set x-bd-client to the registered clientId, x-bd-time to that timestamp, x-bd-nonce to a cryptographically random 24-80 character value matching [A-Za-z0-9_-], and x-bd-signature to the lowercase hexadecimal HMAC-SHA256 of that signed string using the secret exactly as returned at registration. The timestamp window is 120 seconds either side. A nonce is single-use; generate a new nonce and timestamp and recompute the signature for every retry, including after an error. Keep the order idempotencyKey unchanged when retrying the same order and payload. The request limit is 180 per minute per client. ## Amounts Every amount in this API is an integer in the minor unit of the currency. 100000 means 1000.00 EUR, not 100000.00 EUR. The currency is EUR throughout. ## Public test offer 101Ts3t The public catalogue contains the real single-payment offer `101Ts3t`, priced at EUR 0.99. It is available for the public agent test at https://dothat.quest. Orders for this test require the `challenge_id` and opaque `challenge_context_hash` issued by dothat.quest. After a confirmed purchase, the order exposes a privacy-safe receipt reference for verification. Personal and payment data are not published. ## Direct HTTP request bodies These are the raw HTTP bodies, not MCP tool arguments. The base URL is https://branddesign.host/commerce/v1. All calls below are authenticated POST requests with the exact signing contract above. Values inside angle brackets are placeholders; obtain the real values from the stated source before sending. ### Create an order POST /commerce/v1/orders ```json { "idempotencyKey": "", "payload": { "service": "101Ts3t", "language": "en", "brief": { "challenge_id": "", "challenge_context_hash": "<64 lowercase hex characters issued by dothat.quest>" } } } ``` The payload wrapper and idempotencyKey are required. Sending service, language and brief directly at the top level fails validation. A duplicate key with the same normalized payload returns the existing order; a conflicting payload is rejected. For other services use the current catalog service ID and its declared brief fields; language is en or bg. Never invent a challenge ID or copy one from a different test. The order response includes id, accessToken, offer and stages. Preserve the accessToken privately for subsequent calls. It is not an HMAC client secret. ### Accept the returned offer POST /commerce/v1/orders//accept ```json { "accessToken": "", "payload": { "accepted": true, "offerVersion": "", "termsHash": "", "billing": { "type": "person", "fullName": "", "email": "", "country": "", "city": "", "address": "" } } } ``` Accept only under the buyer's authority after checking the returned amount, currency, scope and terms. Use the returned offer hashes, not values copied from an older order. Company billing uses type company and additionally requires company, registration and representative; vat and phone are optional. For a Bulgarian company registration is 9 or 13 digits. The complete field constraints are in the transactional OpenAPI schema. Individual project quotations must be made payable before acceptance; an indicative price is not a payable total. ### Read order and payment status POST /commerce/v1/orders//status ```json {"accessToken":""} ``` This is an authenticated POST with a body, not a public GET. Inspect the returned status, stages, paymentState and any providerEvidence. If a payment response is interrupted or ambiguous, reconcile this existing order and attempt through status before deciding on any further action. Do not create a replacement order to bypass a pending or uncertain payment. ### Start an authorised payment POST /commerce/v1/orders//payment ```json {"accessToken":"","stage":"advance","confirmed":true} ``` The stage is advance for the first payment, including the single-payment 101Ts3t offer; final is only for a separately released final stage. The merchant derives the charge amount and currency from the accepted offer. Without sharedPaymentToken the response contains attemptId and a hosted payment form/session. For autonomous token settlement add sharedPaymentToken containing a valid buyer-authorised Stripe shared payment token granted to the profile in the live manifest. A self-registered agent also needs current DNS domain-control KYA. Do not send a wallet address, USDC balance, card number or an ordinary unrelated token as sharedPaymentToken. confirmed: true records buyer confirmation; it does not create buyer authority. MCP exposes its own tool schemas. Do not reuse a flat MCP create_order argument object as a direct HTTP order body. CLI and WebMCP expose public reads only and cannot create orders, accept offers or start payments. ## Verify domain control before autonomous token payment ### KYA through MCP For the currently authenticated MCP agent, use kya_challenge with contact set to an HTTPS URL on a domain that the agent operator controls, for example {"contact":"https://agent-operator.example"}. OAuth login alone does not verify that domain. The initially mapped OAuth account must supply its own controlled domain; do not use Brand Design Ltd.'s domain as proof of your control. The contact URL may not use an IP address, URL credentials, a custom port or a fragment. Read the returned dnsName and txtValue, publish that exact DNS TXT value under your domain, then call kya_verify with {}. Read the result with kya_status and {}. A successful verification is valid for 24 hours. Starting a new challenge resets prior verification and rotates the challenge. Omitting contact reuses the agent's current contact; supply it explicitly when establishing the correct domain. OAuth scope commerce.order is required for kya_challenge and kya_verify; commerce.read is required for kya_status. These tools use the current OAuth or registered-agent identity, or the same optional clientId and secret arguments as the other MCP tools. KYA verifies domain control only, never the buyer's identity or authority to spend. If the operator cannot publish DNS for a controlled domain, autonomous shared-payment-token settlement is unavailable; the buyer-authorised hosted checkout path remains separately available. DNS TXT KYA verifies control of the agent's HTTPS contact domain. A self-registered agent needs current KYA before autonomous shared-payment-token payment. Challenge: https://branddesign.host/commerce/v1/agents/kya/challenge. Verification: https://branddesign.host/commerce/v1/agents/kya/verify. Status: https://branddesign.host/commerce/v1/agents/kya/status. This is domain-control assurance, not proof of the buyer's identity or authority to spend. Direct discovery, direct order creation and buyer-hosted checkout remain open; UCP authentication also requires a KYA-verified origin. ## Pay Two payment routes are documented below, with different validation status. A hosted payment session. You may complete it yourself with a payment instrument issued to you, or hand the link to the person you act for. This route has been exercised in production, in both forms. A delegated one-time payment token (Stripe shared payment token), settled without a hosted page. This route is implemented and verified against the processor's live API, but has not yet been exercised in production. The processor refuses a token whose granting and receiving parties are the same account, which is why we could not complete it ourselves. ## On-chain payment is not accepted There is no x402 endpoint and no on-chain settlement address. Do not attempt to pay by transferring assets to any address claiming to belong to this company. If your funds are held in digital assets, pay with a payment card issued against them. This works and has been done: on 15 September 2026 an agent wallet funded in USDC on Base settled an order here through a Visa card issued against that collateral. We received euro and issued a normal invoice; the conversion happened at the card issuer, not with us. ## What still needs a person Only services eligible for ordering in the current catalog may be ordered. Payment requires an accepted offer with agreed scope and a concrete payable total. Agentic Commerce and Full Stack require an individual project quote; indicative amounts are not payable totals. Available merchant profiles are acp/2026-04-17 at https://branddesign.host/.well-known/acp.json, ucp/2026-08-25 at https://branddesign.host/.well-known/ucp, and ucp/2026-04-08 at https://branddesign.host/.well-known/ucp/2026-04-08. UCP uses a registered API key bound to a KYA-verified UCP-Agent origin; follow the selected profile for its contract. DNS TXT KYA verifies control of the agent's HTTPS contact domain. A self-registered agent needs current KYA before autonomous shared-payment-token payment. Challenge: https://branddesign.host/commerce/v1/agents/kya/challenge. Verification: https://branddesign.host/commerce/v1/agents/kya/verify. Status: https://branddesign.host/commerce/v1/agents/kya/status. This is domain-control assurance, not proof of the buyer's identity or authority to spend. Direct discovery, direct order creation and buyer-hosted checkout remain open; UCP authentication also requires a KYA-verified origin. Delivery of the work itself is done by people and is measured in days. ## What happens after you pay After settlement is confirmed, the system reconciles the payment, creates a client record and work task, assigns the next invoice number, composes the invoice and sends the notifications. Completion time depends on payment confirmation and processing; the timing of one recorded run is not a guaranteed processing time. ## Record The implementation and the successful externally initiated production run are documented in version 1.3: https://doi.org/10.5281/zenodo.22878834; CC BY 4.0. All versions: https://doi.org/10.5281/zenodo.22767915. Public verification: https://api.dothat.quest/api/verifications/qst_44e153fc16fe3fa91520e5f6922ae4c9. ## If something is wrong Write to contact@branddesign.ltd from the address you registered with. Refusals carry a machine-readable code; quote it. ## Optional agent equipment Optional public files for faster agent orientation: read the compact map, context, access rules and workflow directly over HTTPS or attach Markdown files to a conversation. The ZIP is optional. Interfaces depend on runtime support and grant no permissions. - Quick orientation: https://branddesign.ltd/agent/memory_summary.md - Optional package index: https://branddesign.ltd/.well-known/agent-bootstrap.json - Compact map: https://branddesign.ltd/MEMORY.md - Access rules: https://branddesign.ltd/AGENTS.md - Importable Agent Skill: https://branddesign.ltd/skills/brand-design-commerce/SKILL.md - Download ZIP: https://branddesign.ltd/skills/brand-design-commerce.zip The root SKILL.md remains for discovery. Importing a skill does not issue credentials, connect tools or grant permission to spend. ## Agentic Commerce and Full Stack Agentic Commerce is the commercial transaction layer over the six B2A services. Implementation of agentic commerce connecting discovery, trust, selection, ordering and payment. Brand Design Ltd. operates direct agent commerce alongside ACP and UCP merchant adapters, with DNS domain-control KYA for self-registered agents making autonomous token payments. Agents can discover services, request an offer and complete an authorised order through the supported path. The current merchant manifest and catalog define what is available. Indicative standalone implementation: EUR 3000 one time. The catalog requires an individual project quote. This indicative amount is not a payable total. The project offer fixes the scope, final amount, conditions and third-party costs. Service: https://branddesign.ltd/agentic-commerce; Bulgarian: https://branddesign.ltd/bg/agentic-commerce. Full Stack includes the six B2A layers commissioned together under an agreed scope. Indicative setup: EUR 5200 one time, plus EUR 500 per month. The Brand component is scope-based; this is an indicative package calculation, not a fixed payable total. A final project offer requires agreed scope. Agentic Commerce is included as a bonus when all six services are commissioned together, with a standalone value of EUR 3000; recurring charges remain separate. Project payments: 50% advance before work starts and 50% final payment on completion. No VAT is charged. Third-party costs, advertising spend, licences, hosting and physical production are agreed separately. Package: https://branddesign.ltd/full-stack; Bulgarian: https://branddesign.ltd/bg/full-stack. The published production proof covers the specific externally initiated 101Ts3t test purchase. 101Ts3t is a separate test-only offer, not the Agentic Commerce implementation service or Full Stack. Verification: https://api.dothat.quest/api/verifications/qst_44e153fc16fe3fa91520e5f6922ae4c9. Signed proof: https://api.dothat.quest/api/proofs/qst_44e153fc16fe3fa91520e5f6922ae4c9. Record: https://doi.org/10.5281/zenodo.22878834. Brand Design Ltd. operates direct agent commerce alongside ACP and UCP merchant adapters, with DNS domain-control KYA for self-registered agents making autonomous token payments. Agents can discover services, request an offer and complete an authorised order through the supported path. The current merchant manifest and catalog define what is available. Available merchant profiles are acp/2026-04-17 at https://branddesign.host/.well-known/acp.json, ucp/2026-08-25 at https://branddesign.host/.well-known/ucp, and ucp/2026-04-08 at https://branddesign.host/.well-known/ucp/2026-04-08. UCP uses a registered API key bound to a KYA-verified UCP-Agent origin; follow the selected profile for its contract. The bd-commerce/1 HTTP API remains independently usable alongside ACP and UCP. Its manifest is https://branddesign.host/commerce/v1/manifest and its catalog is https://branddesign.host/commerce/v1/catalog. Agents can self-register and sign authenticated requests with HMAC-SHA256. MCP at https://branddesign.ltd/mcp exposes the same commerce functions through OAuth or registered agent credentials; it is another interface to the merchant API. DNS TXT KYA verifies control of the agent's HTTPS contact domain. A self-registered agent needs current KYA before autonomous shared-payment-token payment. Challenge: https://branddesign.host/commerce/v1/agents/kya/challenge. Verification: https://branddesign.host/commerce/v1/agents/kya/verify. Status: https://branddesign.host/commerce/v1/agents/kya/status. This is domain-control assurance, not proof of the buyer's identity or authority to spend. Direct discovery, direct order creation and buyer-hosted checkout remain open; UCP authentication also requires a KYA-verified origin. Payment can use a Stripe shared payment token granted under the buyer's authority or a hosted payment page. A token is submitted as sharedPaymentToken after the offer has been accepted; the self-registered agent must also meet the KYA requirement. The hosted page may be completed by the buyer or by an agent using an instrument issued to it. Amounts in the commerce API are integers in EUR minor units. HMAC authenticates the request; it does not grant authority to spend. On-chain settlement is not accepted. Only services eligible for ordering in the current catalog may be ordered. Payment requires an accepted offer with agreed scope and a concrete payable total. Agentic Commerce and Full Stack require an individual project quote; indicative amounts are not payable totals. The supported protocols do not change those prices or turn an indicative price into a chargeable offer. Read https://branddesign.host/commerce/v1/catalog for order eligibility and the current offer. Full Stack combines the six B2A services under an agreed project scope and includes Agentic Commerce as a bonus when all six are commissioned together. The agreed scope determines which protocol adapters and integrations are included. The package calculation remains indicative, recurring charges remain separate and an individual offer fixes the payable amount. The separate route qualification at https://api.dothat.quest/api/route-qualifications/{challenge_id} applies after a new 101Ts3t purchase receives base PASS. The order and payment must use the same route, with shared-payment-token payment and current DNS domain-control KYA. The original 2026-09-21 base PASS remains historical evidence; it predates signed route evidence and is NOT_VERIFIED for route qualification. This implementation release does not claim a new real route-qualified PASS. Published ACP and UCP merchant adapters describe implemented interfaces. They do not establish admission to Google or OpenAI native checkout programmes or prove that every external buyer agent can complete a purchase. Version 1.4, published on 29 September 2026, archives the protocol adapters, DNS domain-control KYA and signed route qualification, together with the public documentation. DOI: 10.5281/zenodo.23038829. https://zenodo.org/records/23038829. Historical purchase evidence remains in version 1.3. ### Български Агентна търговия е търговският слой над шестте B2A услуги. Внедряване на агентна търговия, свързваща откриването, доверието, избора, поръчката и плащането. Brand Design Ltd. поддържа пряка агентна търговия и търговски интерфейси за ACP и UCP, с DNS проверка KYA за саморегистрирани агенти при автономно плащане с токен. Агентите могат да откриват услуги, да получават оферта и да извършват възложена им поръчка през поддържания интерфейс. Текущият манифест и каталог определят достъпните възможности. Ориентир за самостоятелно внедряване: 3000 EUR еднократно. Каталогът изисква индивидуална проектна оферта. Ориентировъчната цена не е сума за плащане. Проектната оферта определя обхвата, крайната цена, условията и разходите за трети страни. Услуга: https://branddesign.ltd/bg/agentic-commerce; English: https://branddesign.ltd/agentic-commerce. Full Stack включва шестте B2A слоя, възложени заедно с договорен обхват. Ориентировъчно 5200 EUR еднократно плюс 500 EUR месечно. B2A Brand е с индивидуална цена според обхвата; изчислението е ориентир, а не фиксирана платима сума. Окончателната проектна оферта изисква договорен обхват. Агентната търговия е бонус при общо възлагане на шестте услуги, със самостоятелна стойност 3000 EUR; периодичните такси остават отделни. Плащане по проекта: 50% аванс преди започване и 50% финално плащане при приключване. ДДС не се начислява. Разходите към трети страни, рекламният бюджет, лицензите, хостингът и физическото производство се уточняват отделно. Пакет: https://branddesign.ltd/bg/full-stack; English: https://branddesign.ltd/full-stack. Публикуваното производствено доказателство се отнася за конкретната външно инициирана тестова покупка на 101Ts3t. 101Ts3t е отделна тестова оферта, а не услугата за внедряване на агентна търговия или Full Stack. Проверка: https://api.dothat.quest/api/verifications/qst_44e153fc16fe3fa91520e5f6922ae4c9. Подписано доказателство: https://api.dothat.quest/api/proofs/qst_44e153fc16fe3fa91520e5f6922ae4c9. Запис: https://doi.org/10.5281/zenodo.22878834. Brand Design Ltd. поддържа пряка агентна търговия и търговски интерфейси за ACP и UCP, с DNS проверка KYA за саморегистрирани агенти при автономно плащане с токен. Агентите могат да откриват услуги, да получават оферта и да извършват възложена им поръчка през поддържания интерфейс. Текущият манифест и каталог определят достъпните възможности. Поддържаните търговски профили са acp/2026-04-17 на https://branddesign.host/.well-known/acp.json, ucp/2026-08-25 на https://branddesign.host/.well-known/ucp и ucp/2026-04-08 на https://branddesign.host/.well-known/ucp/2026-04-08. UCP използва регистриран API ключ, свързан с проверен чрез KYA UCP-Agent origin. Избраният профил определя конкретните изисквания. Прекият HTTP API bd-commerce/1 остава самостоятелно достъпен наред с ACP и UCP. Манифестът е https://branddesign.host/commerce/v1/manifest, а каталогът е https://branddesign.host/commerce/v1/catalog. Агентите могат да се регистрират сами и да подписват заявките с HMAC-SHA256. MCP на https://branddesign.ltd/mcp предоставя същите търговски функции с OAuth или регистрирани агентски данни за достъп. KYA чрез DNS TXT проверява контрола върху HTTPS домейна за контакт на агента. Саморегистриран агент трябва да има валидна KYA проверка преди автономно плащане със споделен платежен токен. Предизвикателство: https://branddesign.host/commerce/v1/agents/kya/challenge. Проверка: https://branddesign.host/commerce/v1/agents/kya/verify. Статус: https://branddesign.host/commerce/v1/agents/kya/status. Това удостоверява контрол върху домейн, а не самоличността на купувача или правото да се харчат негови средства. Прякото откриване, създаване на поръчка и плащане от купувача през хоствана страница остават достъпни; UCP изисква и KYA проверен origin. Плащането може да използва споделен платежен токен на Stripe с предоставени от купувача права или хоствана платежна страница. Токенът се подава като sharedPaymentToken след приемане на офертата; саморегистрираният агент трябва да изпълни и KYA изискването. Страницата може да бъде платена от купувача или от агент с платежен инструмент, издаден на него. Сумите в търговския API са цели числа в евроцентове. HMAC удостоверява заявката, но не дава право за разходване на средства. Не се приема плащане във верига. Може да се поръчват само услугите, за които текущият каталог допуска поръчка. Плащането изисква приета оферта с договорен обхват и конкретна крайна сума. Агентната търговия и Full Stack изискват индивидуална проектна оферта; ориентировъчните цени не са суми за плащане. Поддържаните протоколи не променят цените и не превръщат ориентировъчната цена в платима оферта. В https://branddesign.host/commerce/v1/catalog са текущите условия за поръчка и офертата. Full Stack обединява шестте B2A услуги с договорен проектен обхват и включва агентната търговия като бонус при общо възлагане на шестте услуги. Договореният обхват определя кои протоколни адаптери и интеграции се включват. Изчислението за пакета остава ориентировъчно, периодичните такси са отделни и индивидуалната оферта определя сумата за плащане. Отделната проверка на маршрута на https://api.dothat.quest/api/route-qualifications/{challenge_id} се прилага след нова покупка на 101Ts3t с основен резултат PASS. Поръчката и плащането трябва да използват един и същ маршрут, споделен платежен токен и валидна DNS проверка за контрол върху домейна. Основният PASS от 21.09.2026 г. остава историческо доказателство; той предхожда подписаните данни за маршрута и е NOT_VERIFIED за тази отделна проверка. Тази версия на внедряването не заявява нов реален PASS за маршрут. Публикуваните търговски адаптери за ACP и UCP описват внедрените интерфейси. Те не удостоверяват приемане в програми за вградено плащане на Google или OpenAI и не доказват, че всеки външен агент може да завърши покупка. Версия 1.4, публикувана на 29 септември 2026 г., архивира протоколните адаптери, KYA проверката за контрол върху домейн и подписаната проверка на маршрута заедно с публичната документация. DOI: 10.5281/zenodo.23038829. https://zenodo.org/records/23038829. Доказателствата за историческата покупка остават във версия 1.3.