Partner pricing review
Keep 0Gate pricing, limits, fee, spread, and support-tier claims aligned with approved partner configuration.
Partner pricing is not one generic public table. It can depend on account configuration, contract terms, product surface, region, method, asset, entitlement, support tier, and current quote data. Product docs should explain where pricing data belongs, not invent or publish commercial terms.
Review matrix
| Claim type | Safe source | Public docs approach |
|---|---|---|
| Transaction fee shown to user | API response or hosted confirmation screen. | Display in context, not as a universal promise. |
| Partner fee schedule | Partner agreement or approved pricing schedule. | Reference account-specific terms. |
| Spread or exchange rate | Quote/session response and approved wording. | Label as current quote or estimate where appropriate. |
| Rate limits | OpenAPI docs or contractual terms. | Describe behavior generally unless a value is approved. |
| SLA or support tier | Contract or support policy. | Route users to support@0bit.io or partner portal where appropriate. |
| Revenue share | Commercial agreement. | Keep out of generic developer docs. |
Public wording defaults
Use defaults like:
- "Pricing and availability can vary by account, region, method, asset, and current quote."
- "Use the values returned by the API or hosted confirmation screen for the specific transaction."
- "Contractual pricing, support, and revenue-share terms are handled through partner agreements."
- "For account-specific pricing questions, contact support@0bit.io."
Implementation rule
Developers should not hard-code marketing pricing into integration logic. Store quote/session/transaction values returned by 0Gate, show approved values to users, and reconcile the final backend event before closing the order.
type PricingDisplay = {
quoteId?: string;
displayAmount: string;
displayCurrency: string;
expiresAt?: string;
source: 'api_response' | 'hosted_confirmation' | 'partner_terms';
};