lachyg

Congratulations! This looks really great. What've you found to be the best hands / end effectors these days? When do you think we'll have good, reliable 5 finger hands that are ~reasonably priced?

(I work at Pi.)

We open-sourced Pi0 (referenced in this post): https://github.com/Physical-Intelligence/openpi

Off the shelf robots -- we've got our models running on dozen+ different robot types (and have this specific generalization demo working on multiple platforms too.)

I'll bite. I _worked_ at Stripe. Stripe has no authority in decision making here, the issuing bank decides (eg the customers bank) who wins and losses chargebacks. Stripe is a conduit of information, not a party to the decision.

(I work at π.)

Happy to answer any questions on the model, hardware, etc

(i'm an investor in the company, and invested over 3 years ago.)

this product has always been about AI—what they launched is almost exactly what they pitched me. their expectation of where the world going ended up being prescient.

(i'm an investor in the company.)

this is probably the most privacy-forward hardware device on the market—you have to physically be making contact with the device for it to begin listening (at which point an LED is prominently visible) and it will stop listening as soon as you break contact.

I believe they're looking to imply here that they own their own charter, rather than renting someone else's, which is how almost all U.S. fintech companies operate (look in the website footer of, say, Unit and you'll see: "Banking services are provided by Unit's partner banks who are Member FDIC.")

Stripe Reader may be a more accurate link: https://stripe.com/terminal/stripe-reader. This is Stripe announcing its own own hardware that developers can use to build their own point of sale payments experiences.

Is there more that can be read on this somewhere? How it's taxed, what're the implications, how is it structured?

Is contributing to the fund a taxable contribution? I would assume so since it's a diversifying event.

There is a demo request form, but no information on whether it's generally available. Is it?

We play the role!

We do :-) But it's based on quite precise Visa / Mastercard rules.

(I work on Issuing.) Our product philosophy is making things as widely available as possible; we won’t be shy about letting the world know when we do.

(I work on Issuing.) Check out https://emburse.com/ -- they do this really well (and are a user!).

It depends on the type of card issued/use case, but prepaid cards issued through Stripe Issuing would still have that same challenge :-( We agree it's a pretty sub-optimal user experience.

(That said, given many of these businesses may be on Stripe, we should have more ability to work with them to improve the experience for customers...)

Great use case! If you fill in the form at https://stripe.com/issuing (or email me at [email protected]) we'll get back to you soon.

(I work on Issuing.)

The technology we've built is agnostic to debit or credit -- it really depends on your use case. That said, force posts (or transactions cleared without an underlying authorization) can happen on any card type.

For what it's worth, we have an API to initiate disputes (which you would be able to on a transaction initiated without a valid authorization) which you could use to recoup funds.

Yes!

(I work on Stripe Issuing.)

We've been primarily focused to date on companies where issuing cards is core to providing their business to customers, for example a startup that provides expensing customers, or a platform that needs to purchase goods in the real world. We're less focused on a business just using it for their own expensing (as we don't have receipt upload functionality, etc).

To your two other questions though:

(1) Could users approve things in real time? Sort of. We provide the ability (as you noticed) through API, but it needs to be responded to in < 2s, which means it's not possible for a human to be in the flow.

(2) Could this be linked to an external bank account? Again, sort of. To get in the weeds: as soon as we approve an authorization, we're on the hook for those funds. A debit to an external balance (or bank account) may fail and Stripe would be on the line. This is why we typically require funds to be in a Stripe account prior to purchases taking place.

(I work on Issuing.)

Not really. We make it easy for institutions like Monzo to issue and manage cards, but I imagine that's just a fraction of what they've needed to build to run a regulated bank, service their customers, etc etc.

Absolutely happy to talk about travel use cases -- we are supporting it today. We also (only) support custom designs.

Emburse are great! They provide far more in the way of user a user experience to set controls, manage budgets, etc. We'd highly encourage going with them! (Stripe Issuing is an API-first product -- if you want to build software like Emburse, we would be more suitable.)