Current product document · reviewed July 28, 2026
BluGives product model and principles
This document replaces the earlier concept paper. It describes the current web product without presenting future ideas, unsupported comparisons, or growth goals as operating facts.
Purpose and scope
BluGives is a web application for person-to-person giving. It provides donor and recipient accounts, recipient profiles, a donation-selection flow, a fee summary, third-party payment integration, and account-level transaction context.
BluGives is not presented as a registered charity, a bank, an investment product, an escrow service, or a guarantor of a recipient's statements or future behavior. A direct payment between individuals is generally treated differently from a tax-deductible gift to a qualified nonprofit.
Current model
These are the primary behaviors visible in the current application. Availability can still depend on account eligibility, the configured API, and third-party payment-provider support.
A person registers as a donor or a recipient. Both paths confirm email access with a one-time code. Recipient accounts can be asked to connect a social profile for additional review context.
Recipient profiles can include a story, location information, activity context, and a social-account review status. Those fields are inputs to a donor's decision, not a guarantee.
A signed-in donor chooses a recipient, selects an amount within the product limits, reviews the fee calculation and recipient amount, and continues to the configured payment provider.
The application can associate a completed payment with the donor account, recipient, amount, payment status, and available recipient updates.
Fee model
The current donation flow deducts a 3% payment-processing fee and a 2% platform fee from the amount entered. The exact fees and the recipient's net amount are shown before payment.
In the current calculation, the amount entered is the gross amount. The recipient net amount is the gross amount minus both displayed fees. That means earlier “zero platform fee,” “no deductions,” and “100% reaches the recipient” language was inaccurate and must not be reused.
If the payment provider, pricing model, or party responsible for a fee changes, the transaction code, Terms, FAQ, fee explanation, and comparison content must change in the same release.
Recipient status and trust signals
Recipient profiles may display a social-account review status and trust signals. These signals provide context, but they are not a guarantee of identity, need, future behavior, or how funds will be used.
The application supports review states for linked social-account information. Email confirmation shows control of an inbox. Social-account context and a platform status may help identify inconsistencies, but they are not substitutes for documented legal-identity, background, financial, or proof-of-need checks.
Future identity or situation-verification features must be described only after the exact checks, vendors, review ownership, retention rules, appeal path, and limitations are documented and operating.
Payment and record boundaries
The configured third-party payment provider controls parts of payment authorization, account eligibility, availability, reviews, holds, and settlement. BluGives should not promise universal payment support, instant settlement, or a specific provider outcome.
A transaction record can show what the application received about a donation. It does not independently audit a recipient's later use of funds. Recipient updates should always be labeled as recipient-provided unless an external review process is actually performed.
Important limits for donors
- A profile status is not a guarantee of identity, need, conduct, or fund use.
- A direct gift is generally non-refundable after disbursement under the current Terms.
- A BluGives transaction record is not a charitable tax receipt.
- Never share passwords, one-time codes, full card details, or identity documents by email.
- Do not continue if someone asks you to pay outside the normal BluGives payment flow.
Product and publishing principles
Public pages should distinguish current behavior from future ideas. A planned feature, market, payment method, moderation process, or governance model must not be presented as operational.
A donor should see the gross amount, processing fee, platform fee, total fees, and recipient net amount before continuing to the payment provider.
A review status should state what information it uses and what it does not prove. Strong terms such as identity verified, thoroughly vetted, or background checked require a documented operating process and evidence.
The platform should collect and display only the information needed for account operation, profile context, payments, safety review, and legal obligations. Sensitive information should not be requested through public support email.
Product decisions should use privacy-conscious events for recipient viewed, signup started, signup completed, donation started, and payment outcome. Marketing claims should never be inferred from unverified analytics.
When product behavior changes, fee pages, Terms, FAQs, structured data, social previews, and machine-readable descriptions must be updated together.
Future work is not a commitment
Public recipient browsing, a shorter registration flow, stronger documented verification, broader payment availability, additional moderation tools, internationalization, and improved outcome reporting may be considered. They remain future work until shipped, tested, and reflected in the current product documentation.
Corrections and questions
Send factual corrections to giveablu@gmail.com. Do not include passwords, one-time codes, complete payment details, or unnecessary sensitive information.