Just to clarify: Unattach does not corrupt or mangle emails. Because Gmail does not expose an API for modifying the original email in place, Unattach creates a new version of the email with attachments removed/downsized while preserving the email's content and metadata.

If you need the original email for legal/evidence purposes, you can back it up first, either through Gmail or Unattach.

Comments URL: https://news.ycombinator.com/item?id=45992696

Points: 7

# Comments: 0

Small Transfers is for usage-based billing of online services and APIs. There is no monthly budget, wallet, or pre-funding. Customers are charged only for actual usage.

Small Transfers is an API for a merchant to charge a customer tiny amounts (as little as $0.000001), which are batched into a single card charge via Stripe.

It's not a PayPal remake, since there are no wallets, no P2P transactions, and no stored funds. In addition, Small Transfers allows very small charges (as mentioned above), and provides customer OAuth and spending caps.

You can charge as little as 0.000001 USD per request. The platform uses our own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.

If combined with subscriptions, the pricing can work similarly to mobile plans, where monthly plans become cheaper above a certain usage threshold.

Looking for more developers to try it and share feedback.

Resources: integration guide (https://smalltransfers.com/merchant/docs/integration-guide), a quick walkthrough (https://youtu.be/WQW5fiUFNRk), a Next.js template (source code: https://github.com/smalltransfers/nextjs-starter, live demo: https://nextjs-starter.smalltransfers.com/), an AI template (source code: https://github.com/smalltransfers/ai-starter, live demo: https://ai-starter.smalltransfers.com/).

On PAYG, you can target the largest emails first and stop whenever you've freed enough space. For example, processing 300 of the largest emails at $0.01 each is about $3; if they average around 10 MB, that's 3 GB freed.

We plan to provide the classic "Google Sign-In" style pop-up window instead of a redirect. Research indicates that it can increase conversion by approximately 5-10%.

Additionally, we are considering a white-label onboarding flow. If the merchant provides proof of customer identity, we can also skip the sign-in step. Both of these should help improve conversion rates.

A fully embedded solution is possible, but it would require the merchant to collect the customer's card details on Small Transfers' behalf (using Small Transfers' Stripe publishable key), which complicates things from both implementation and legal perspectives.

  - The customer has to pay upfront, which lowers conversion rates.
  - No shared balance across multiple merchants, resulting in higher total payment processing fees.
  - As you already noted, trust shifts to each merchant to honor unused balances.

If you are suggesting that the max-owed limit is actually N×X, then that would multiply worst-case exposure by N, which is undesirable.

If you are suggesting that we charge the customer when they owe X while their max-owed limit is N×X, this would be worse for the customer, since they would pay `N × (X × variable_rate_fee + fixed_rate_fee)` instead of `N×X×variable_rate_fee + fixed_rate_fee` in payment processing fees.

Even if longer holds were possible, using authorization holds as a prepayment proxy can raise regulatory/consumer-protection issues similar to holding customer funds.

Paying the merchant before the customer's card payment settles would mean advancing funds, which would start to resemble lending/guarantee rather than payments, raising regulatory issues. It would also concentrate risk at the platform: defaults from one merchant’s customers could jeopardize the platform for all merchants.

  - Each merchant requires an OAuth grant, and customers can revoke it at any time.
  - A customer ledger shows what, when, and how much each merchant charged. This can be shown in the customer's dashboard and monthly statement emails.
  - Customers have account-level spending caps to limit exposure. We will add per-merchant caps.
  - If patterns look off or we get complaints, we can pause new charges and review.