strnisa

Founder of Unattach here.

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.

It seems to me that major US cloud companies are using politics to try to get more value from non-US data, which I believe will push the EU (and others) to accelerate the move to their own alternatives. This is another move that seems to sacrifice longer-term trust (and profits) to boost near-term profits.

From what I can find, Gripto was a cryptocurrency platform for viewing holdings, market info, and relevant news. It seems that the service was retired in late 2018.

Flattr was a micro-donation subscription service where users set a monthly budget that was allocated to creators.

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.

BLIK is a bank-backed payment method used at checkout.

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.

If a customer's balance is under $1 at the end of the month, we delay charging them for up to 60 days and send email reminders. If it's still under $1 after 60 days, we charge at least $0.50 and credit the difference (after fees) to their account for future use.

Customers do create an account and provide a payment method, but they don't pre-fund or hold a balance, and they don't initiate a payment. Small Transfers is an API that allows merchants to charge very small amounts programmatically. At the end of each month (or earlier, if a threshold is reached), we charge the customer what they owe. This makes the tiny charges viable and avoids death-by-$0.30.

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.

I understand not wanting another subscription. You can subscribe and then immediately turn off auto-renewal — your access stays active for the full year you paid for.

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.

You're correct that this adds a barrier to entry, but for many users, that hurdle is still lower than asking them to start a subscription or buy a prepaid bundle.

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.

I misunderstood this comment originally. In principle, Small Transfers (ST) could let a content site bill AI agents per request. Each site (acting as an ST merchant) would expose a simple "content" endpoint. The AI agent (as an ST customer) would perform a headless OAuth flow, after which the content site could charge for access. We currently don't support headless OAuth, but if anyone is interested in exploring this use case, please get in touch.

That's an interesting idea. This may avoid the e-money issues, but:

  - 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.

The key legal issue is interchangeability. Single-merchant vouchers are generally acceptable. If a voucher can be used across multiple merchants, it's often treated as e-money in the EU. Not being able to use funds across multiple merchants would significantly reduce the value for customers, as they would no longer be able to share payment processing fees across merchants.

I see what you mean — yes, this could be useful to some customers. We already implement a small grace amount above the max-owed limit that allows for continued service; your idea would essentially allow the customer to increase the default grace amount.