Brand Design Ltd.

Start here: the information desk of Brand Design Ltd. Without a question: who Brand Design Ltd. is, what it does, its clients and results and who confirms them, with links to check, and the next steps. With a question: an answer about the agency, its services, prices and how to order, from verified company knowledge, in the language of the question, with sources. When your principal wants to order, it can also prepare the offer with a checkout link, beside catalog and create_order here; it never accepts an offer or pays. Questions need no credentials. An offer is prepared only for a verified robot (signed by its maker or from the published addresses of its maker), as for create_order; credentials are optional. If your principal asks to be contacted, it can pass the enquiry to the founder. Pass the returned session to continue.

Introduce yourself and the person or company you act for, and pass their enquiry to Nikola Mishev, the founder of Brand Design Ltd., by e-mail. He replies to the contact you give. Use it only when your principal wants to be contacted. No credentials needed.

Read the service catalogue: names, prices, currency and terms. No credentials needed. All amounts are integers in the minor unit; 100000 means 1000.00 EUR.

無需輸入參數。

Read the commerce manifest: protocol, endpoints, authentication scheme, payment instrument and limits. No credentials needed.

無需輸入參數。

Register yourself and receive a client identifier and a secret. No approval and no prior arrangement. The secret is returned once and cannot be recovered. Put them in the Authorization header as "Bearer <clientId>:<secret>" for the other tools.

Adds the owner limit: a verified DNS record on your own domain lets your owner cap the amount per order and withdraw your right to pay by removing it. The mandatory domain verification is against the domain of your maker. Issue a fresh DNS TXT challenge for your currently authenticated agent identity. Needs commerce.order for OAuth. Supply an HTTPS contact URL on a domain you control, especially on the first OAuth connection. Omitting contact reuses the current contact. This replaces the previous challenge and clears its verification. Publish the returned txtValue at dnsName, then call kya_verify. Domain control does not establish buyer identity or grant spending authority. Do not publish secrets in DNS.

Check the DNS TXT challenge for your currently authenticated agent and record domain-control verification. Needs commerce.order for OAuth. First call kya_challenge and publish its exact DNS TXT record. The response gives verifiedAt and validUntil; verification is currently valid for 24 hours and is read again from DNS at every create_order, accept_offer and start_payment, which all require it. It does not grant buyer payment authority.

Read DNS domain-control verification for your currently authenticated agent. Needs commerce.read for OAuth. Returns verification status and, when present, DNS instructions and validity timestamps. This does not change the contact, challenge or verification.

Place an order for a service. Needs credentials. Returns the order id, the offer and an accessToken you must keep for the following calls. The offer is pinned to the hash of the service page; accept_offer needs offer.version and offer.terms.<language>.hash from it. Services without a catalogue price return an offer with no total and wait for a person to price it. The request must come from a verified robot: signed by its maker (Web Bot Auth) or from the published addresses of its maker. Errors: KYA_VERIFICATION_REQUIRED (403) without it, MISSING_<field> when a required brief field is absent, UNEXPECTED_FIELD when the brief has a key the service does not declare.

Accept the offer on behalf of the buyer. Needs credentials. This locks the billing identity, the offer version and the hash of the terms as they stand at this moment. A later change to the website cannot pass for what was agreed. The request must come from a verified robot. Errors: KYA_VERIFICATION_REQUIRED or KYA_REVOKED (403) without it, OFFER_CHANGED (409) if the offer or the terms changed since you read them; read order_status and use the new values. OFFER_EXPIRED (409) 30 days after the order. MANUAL_OFFER_REQUIRED (409) while a person has not priced the service yet.

Start payment for a stage. Needs credentials. Without sharedPaymentToken you receive the link to our payment page (form.redirect), which you may complete yourself with a card issued to you, or hand to the person you act for; on that page the card must be in the name on the invoice (for a company: its representative or the company name) and the cardholder address must be in the invoice country, and every order placed by an AI agent needs the cardholder to confirm with the bank (3-D Secure). With a delegated shared payment token the payment settles directly. The request must come from a verified robot: signed by its maker (Web Bot Auth) or from the published addresses of its maker. If the owner of the agent verified a DNS record with kya_challenge and kya_verify, the record is read again at payment and its limit applies; kya_status reads it. KYA does not grant buyer payment authority. On-chain payment is not accepted. Errors: OFFER_EXPIRED (409) for an advance after 30 days, FINAL_NOT_RELEASED (409) when the final payment is not open yet, OWNER_APPROVAL_REQUIRED (409) for a first order above EUR 1000 from a new e-mail or card until the merchant approves it, BUYER_BLOCKED (403), PAYMENTS_DISABLED (503).

Read the current state of the order, its offer and its payments, including the invoice number once one has been issued. Needs credentials.