Payment Policy version · September 10, 2026 · Version 2026-09-10-r11

Payment, Cancellation, Refund and Dispute Policy

Defined roles: A “Client” is a person or organization that requests or purchases Provider Services through Herald. A “Provider” is a person or organization that offers or performs those services. A user may act in either or both roles. This is a non-substantive terminology clarification and does not change any accepted right, obligation, fee, or deadline. Other capitalized terms have the meanings stated in the Terms of Service.

1. Before payment

A service request does not create a payment. The client chooses immediate activation after payment or a specific future start date. Directory readiness is planning information, not paid lead time; a provider who cannot meet the requested schedule must propose a later date before accepting. The provider has up to 24 hours to accept, request changes, or decline. The client has up to 24 hours to respond to changed terms and, after acceptance, up to 24 hours to pay. These are expiration limits, not required waiting time. Either party may withdraw or decline before payment, and an unpaid request may expire. Providers must not begin before confirmed payment or the agreed future start.

2. Price, token quantity, and fees

Bookable Provider Services must have a total service value of at least $25.00. The client pays the frozen compensation and no separate Herald client fee. Herald deducts a 10% Herald provider fee from each approved or released checkpoint. The client sees the frozen service value and complete checkout total, and the provider sees the provider fee and calculated 90% net before commitment. Final acceptance alone creates no charge. For a project-token booking, Stripe payment remains provisional and Herald earns no fee until Herald verifies the required initial token transfer. If that transfer is not verified within the displayed 24-hour window, or the client cancels during that window, Herald unwinds the booking and refunds the complete Stripe charge. After funding, Herald earns its 10% fee only on checkpoint value that is approved, released, paid to the provider, or otherwise finally awarded to the provider. If unstarted, undelivered, unreleased, or client-blocked work is refunded under Herald’s rules, the allocated Herald provider fee for that refunded work is also returned except where law, a payment-network decision, correction of a duplicate or erroneous payment, fraud, chargeback, or separately incurred third-party cost requires a different result. A full refund of unreleased service value therefore returns the refundable Stripe charge for that work and pays the provider nothing for that refunded work. Separate third-party payment, payout, bank, network, wallet-provider, currency-conversion, withholding, or tax charges may apply as disclosed by the applicable provider.

An accepted service may include fiat compensation, an eligible Solana or BNB Smart Chain project token, or both. Direct project-token compensation is limited to a project’s own token. Stablecoins, SOL, BNB, wrapped or staked versions, and other general-purpose payment or network assets are not eligible and may be rejected by Herald. Stablecoins offered through Stripe Checkout remain only a method of satisfying USD-denominated fiat compensation. For a project-token portion, Herald uses Jupiter Price API V3 for Solana or DEX Screener market data for BNB Smart Chain to estimate current fair market value (“FMV”) when the client accepts the final proposal. Herald then records and freezes the gross token quantity and the 90% provider-net token quantity. The client remits the token portion’s 10% Herald fee in fiat at Stripe Checkout, sends the first checkpoint’s exact provider-net token quantity during the initial funding window, and transfers later portions across the remaining recorded checkpoints.

The token quantity is fixed; its later market value is not. The client commits to send and the provider agrees to accept as the complete token portion of compensation the exact frozen provider-net token quantity, even if its FMV rises or falls before transfer. Market-price changes alone do not alter the quantity, require a top-up or reduction, permit another token or fiat substitute, change the Herald fee, or create a refund right. The FMV snapshot is an accounting estimate, not a promise that the token can be sold for that amount. Tokens without a usable supported market price are not eligible.

The fixed Brigid Forge Featured Provider product is different from a Provider Service. It is a one-time $50 purchase with no additional Herald service fee. An abandoned or cancelled Checkout creates no service. After Stripe confirms payment, Herald activates 30 days of the disclosed visibility and transfers payment automatically; there is no delivery payment, proof requirement, client approval, or delivery-review period. A completed visibility purchase is nonrefundable except for duplicate or erroneous payment, fraud, chargeback, legal obligation, or non-waivable consumer rights. If Herald ends a paid Featured entitlement before its scheduled expiration, Herald records the termination and opens a refund review. Herald ordinarily returns the full purchase to the original payment method unless documented fraud, abuse, chargeback, illegality, legal obligation, payment correction, or another stated exception supports a different result; the refund or exception decision and Stripe references are retained in the purchase record.

3. Stripe, direct token transfers, and payment status

Stripe processes the fiat compensation, the fiat-denominated Herald fee attributable to project-token compensation, and provider fiat payouts. Herald’s fee calculations and agreement-time FMV snapshots remain denominated in USD. Checkout may offer cards, Apple Pay, Google Pay, and eligible Stripe-supported stablecoins such as USDC. Stablecoin Checkout payments are converted and settled into the platform’s Stripe balance in USD. Opening Checkout, submitting payment details, or initiating a wallet transaction does not prove funding; Herald relies on Stripe’s signed confirmation.

The client pays the complete fiat Checkout total upfront; a project-token booking’s direct token portion is instead funded checkpoint by checkpoint. For a project-token booking, Stripe confirmation opens a 24-hour initial token-funding window but does not activate the service. The client must send the first checkpoint’s exact frozen provider-net token quantity directly to the recorded provider wallet and then ask Herald to check payment. Herald scans the applicable chain for confirmed transfers of the recorded token to that wallet during the payment window and records the matching transaction identifiers; the client may provide a finalized transaction signature or hash if automatic discovery does not find a payment. Multiple unique confirmed transfers may be added together for the same checkpoint. An underpayment leaves the checkpoint pending and Herald displays the exact remaining quantity; the checkpoint is satisfied only when confirmed receipts total at least 100% of its frozen quantity. Herald also verifies transaction success, confirmation, timing, and prior use before marking the booking funded and telling the provider to begin. Until that verification, the complete Stripe charge is refundable, Herald earns no fee, no delivery clock begins, and the provider must not start. If verification is not completed in time, Herald cancels the booking and initiates a full Stripe refund.

After a checkpoint is approved or released, the next project-token portion becomes due. The client must send it, and Herald must verify confirmed receipts totaling at least 100% of that checkpoint’s exact frozen quantity, before the provider begins the next work period. Until verification, that work period and its deadlines remain paused and the provider must wait. The same automatic discovery, optional transaction-identifier fallback, aggregation, and underpayment rules apply to every checkpoint.

A transfer of the wrong token or to the wrong network or wallet; a deficient aggregate quantity; a failed, late, or unconfirmed transfer; or a false, altered, unrelated, or reused identifier is not complete payment. Project tokens are not paid to or held by Herald. Users are responsible for wallet control, correct addresses, chain compatibility, token-transfer restrictions, sufficient token and native-network balances, gas or network charges, and independent tax and legal compliance. Herald cannot retrieve a transfer sent to the wrong address or chain and cannot force a wallet, token contract, or blockchain to process or reverse a transfer. This is not a bank, trust, insurance, custody, or legal escrow service. Stripe, payment networks, blockchain networks, wallet providers, and financial institutions determine final processing.

4. Automatic payment checkpoints

Every new service states the exact work, total price, and number of service days. Herald automatically creates a payment checkpoint every three service days and on the final service day if it comes sooner. Examples: a one-day service has a Day 1 checkpoint; a five-day service has Day 3 and Day 5 checkpoints; a seven-day service has Day 3, Day 6, and Day 7 checkpoints.

The client pays the complete fiat Checkout amount upfront. If the agreement includes project-token compensation, the direct token portion is divided across the same checkpoints and funded separately before each corresponding work period. Each checkpoint’s value is proportional to the number of service days it covers. For a seven-day service, the checkpoint values cover 3/7, 3/7, and 1/7 of the service price. Any cent or token base-unit rounding remainder is assigned to the final checkpoint. The complete schedule and exact amounts are shown before payment.

For a fiat-only booking, payment or the accepted future date authorizes work. For a project-token booking, both the applicable start date and Herald’s verification of the required checkpoint token payment control work authorization. For an immediate multi-day service, initial funding at or before 12:00 noon in the frozen provider timezone makes that date Service Day 1. After-noon initial funding authorizes work immediately, but the following date becomes Service Day 1. Each later work period remains paused until its token portion is verified. Checkpoint proof submission opens on the displayed checkpoint date and remains due by the end of that date. Payment timing and early completion do not move later checkpoint dates.

5. Proof, acceptance, pauses, and corrections

Proof is due by the end of each checkpoint day in the provider’s frozen timezone. At delivery, the provider may submit one or more work URLs, up to six images, a written completion note, or any combination of those options. At least one URL, image, or nonblank note is required. A completion time defaults to the current time and may not predate confirmed payment or the applicable service period. Herald permanently retains each submitted proof version and its images.

The client may approve immediately, which releases that checkpoint payment immediately. Otherwise payment releases 24 hours after proof submission unless the client reports a specific objective mismatch with the frozen service agreement. Work may continue during this routine 24-hour review. A valid issue report holds the challenged payment and pauses future work and deadlines while the provider corrects, refunds, or contests it. Previously released checkpoint payments remain settled except for fraud, reversal, or legal requirement.

If checkpoint proof is missing, its payment does not release and the next work period pauses. A final 24-hour cure remains available. Proof during cure is recorded as late cured. If cure expires without proof, Herald refunds the refundable portion of the affected checkpoint, including its allocated Herald fee under this r11 policy; eligible future unperformed work follows the continuation or refund process.

6. Deliverables, not performance outcomes

Herald payments cover completion of the frozen objective work. Impressions, views, engagement, clicks, conversions, sales, revenue, return on investment, price movement, token performance, and similar audience or business outcomes are not guaranteed delivery requirements and are not grounds to pause work or withhold a delivery payment. Providers may present accurate, date-qualified historical statistics, but historical performance does not promise a result for a particular service. Standard Herald services may not offer guaranteed performance outcomes.

A suspected material falsification of provider statistics is handled as a separate provider-accuracy or marketplace-integrity report. It does not automatically convert a completed objective delivery into non-delivery.

7. Cancellations and dependencies

8. Exceptional formal review

Late proof and provider silence are handled automatically, not by dispute. Ordinary nonconformance first uses correction, refund, client withdrawal, retained messaging, and a 24-hour direct-resolution period. A provider disagreement—or a client’s continuing objection after correction—does not immediately create an admin case. Both parties see the deadline and receive essential reminders. Only an unresolved contested issue, fraud, safety, illegality, payment error, or another issue the automatic rules cannot decide may escalate.

The contested delivery payment remains held and future work pauses. Each party generally has five business days after formal-review notice to submit evidence. This longer evidence period is intentionally separate from routine 24-hour action clocks. Both parties can see submission status, the amount under review, and the final rationale and calculation. Herald targets a reasoned outcome within ten business days after evidence closes.

9. Outcomes, enforcement, and continuing publication

Herald may determine that formally contested service value should be refunded, paid, or proportionally divided. A rationale and resulting Stripe or blockchain identifiers are retained. A payment release cannot outrun a valid refund marker, unresolved objective problem, client dependency, or missing or deficient required project-token transfer. A verified direct token transfer is not held by Herald and cannot be reversed by Herald. Unpaid future token portions are not sent after a valid termination; any voluntary return of tokens already transferred must be arranged and recorded by the parties. Legacy bookings retain any refund required by their frozen policy.

Failure to make or truthfully document an agreed token transfer; a false, failed, altered, unrelated, or reused transaction identifier; transfer of the wrong token, quantity, wallet, or chain; market-data or liquidity manipulation; fee avoidance; or other fraudulent or abusive conduct may result in rejection of the transfer, paused work or eligible fiat release, cancellation of unpaid future work, additional verification, loss of verified-review eligibility, payout delay or hold where lawful, recovery or setoff, feature restriction, suspension, delisting, account termination, evidence preservation, notice to affected providers or service providers, and reporting or cooperation with authorities. Herald may act immediately without prior notice when it reasonably believes fraud, illegality, sanctions, security, safety, payment, or marketplace-integrity risk requires it. These remedies do not let Herald reverse a direct token transfer and do not eliminate non-waivable rights.

Published service content must remain available while the provider controls it and continued publication is lawful, safe, and platform-permitted. The provider supplies the public content URL with delivery proof, and Herald freezes it in the shared record as the URL eligible for a later availability report. This obligation does not delay routine payment release. A reported removal gives the provider 24 hours to restore it or document one permitted reason: a client instruction, a legal or safety requirement, platform-enforced removal, or loss of account control. The provider must record the category, specific facts, dates, and supporting links in the shared booking record. An unexplained controllable violation may lead to suspension or delisting but ordinarily does not reopen completed payment.

10. Refund delivery and non-refundable charges

Approved compensation refunds are submitted to the original payment method after subtracting only fees that have already been earned on approved, released, paid, or finally awarded work. Card and card-wallet refunds return through the applicable bank and card network. Stripe-supported stablecoin refunds return as stablecoins to the original wallet under Stripe’s process; blockchain confirmation time and the asset or amount delivered are governed by Stripe’s refund implementation and applicable network conditions. Herald’s 10% fee is non-refundable only to the extent it has been earned on completed or awarded work. Stripe processing, Connect, currency-conversion, bank, wallet-provider, and blockchain-network fees actually incurred are non-refundable and are not credited by Herald except where applicable law or the responsible third party requires otherwise. If a refund is pending because the platform balance, payment provider, or network requires additional processing, Herald will preserve the refundable obligation and continue reconciliation.

11. Chargebacks and payment-method rights

Cardholders retain non-waivable payment-network rights. A card or card-wallet chargeback is separate from Herald’s booking process and is decided by the issuing bank or network. Stripe stablecoin payments do not provide a card-network chargeback process; eligible booking concerns must use Herald’s dispute process and any non-waivable legal rights. Users must not pursue duplicative recovery and must cooperate with evidence requests. Herald may pause payouts, reverse transfers, suspend an account, or offset amounts connected to a refund, chargeback, fraud event, or payment error.

12. Contact

Questions about a payment or service dispute should be submitted through the shared workspace or to [email protected].