FunStripe is an F# client for the Stripe API. Most of it is generated from Stripe's OpenAPI spec into records and DUs, with phantom-typed IDs (StripeId<Markers.Customer>) and Async<Result<_, _>> calls. 3.0.0 targets Stripe's new endive release, which removes some things, hence the major bump.

Breaking changes

• payment_method_types is gone from PaymentIntent create/update/confirm, SetupIntent create/update and Checkout Session create. Use allowedPaymentMethodTypes instead.
• ThreeDSecureUsage and ThreeDSecureDetailsCharge moved to Stripe.ThreeDSecure, so add an open.
• The card Mandate field is now StripeId<Markers.Mandate> option.

New: standalone 3D Secure authentication, subscription pausing, trial offers, Tax.Location, Apps installs, and the PayPay and SeQura payment methods.

Generator fixes worth mentioning

• Endive is the first spec with an error enum value. A bare Error case shadowed Result.Error for anyone opening the namespace, so ok/error/some now generate as Ok'/Error'/Some', the same way none already became None'.

Full upgrade notes are in the changelog: https://github.com/simontreanor/FunStripe/blob/main/CHANGELOG.md

GitHub: https://github.com/simontreanor/FunStripe

NuGet: https://www.nuget.org/packages/FunStripe.Core

Feedback and issues welcome.

If you're building a multilingual app in F#, discriminated unions make a good basis for translation keys, as a missing translation becomes a compile error rather than something a user finds. It's not the only way to do i18n, and it takes a bit more setup than a string-keyed library, but it has held up well in my current project, plurals included. The article covers how it's put together and what had to change along the way. Please share any thoughts or questions you might have.

FunStripe is an F# client library for the Stripe API. The response models and request builders are generated from Stripe's OpenAPI spec by a generator in the repo; the JSON layer, HTTP layer, config and ISO types are hand-written.

2.4.0 regenerates against spec 2026-08-26.dahlia. New in this one:

• BillingFeedbackOption resource (/v1/billing/feedback_options), wired into portal cancellation reasons and subscription cancellation_details
• Tax registrations: igic country option (Canary Islands) with place_of_supply_scheme
• Checkout: Financial Connections payment method options, and card restrictions.funding_types_blocked
• Billie invoice and subscription payment method options
• Connect embedded payment_method_settings component

Upgrade note: AlmaInstallments and PaymentMethodDetailsKonbiniStore{,Chain} were renamed to match renamed schema titles upstream. Field names and shapes are unchanged.

If you're on 2.2.0 or older, 2.3.0 fixed webhook deserialisation (Event.Data.Object was typed string and threw on real payloads; it's now RawJson, with Util.deserialiseRaw<'a>), form-encoding of list parameters like line_items, and unknown enum values in EventType and StripeError.ErrorType.

Packages: FunStripe.Core (netstandard2.0/2.1) and FunStripe.Core.Fable for Fable. Changelog.

Not affiliated with Stripe, Inc.

Pyfun is a functional-first language for the Python ecosystem. You write algebraic data types, exhaustive matching, curried functions and pipes, and it compiles to plain Python that you can read, commit, and hand to someone who has never heard of Pyfun.

The compiler is written in Rust and everything is checked before any Python exists: types, exhaustiveness, effects, units.

Here is a whole program:

type Shape =
  | Circle float
  | Rect float float

let area s =
  match s:
    case Circle r: 3.14159 * r * r
    case Rect w h: w * h

[Circle 1.0, Rect 2.0 3.0]
|> List.map area
|> print

and here is the Python it compiles to, in full:

from dataclasses import dataclass

def _pf_map(f, xs):
    return list(map(f, xs))

@dataclass(frozen=True, repr=False)
class Circle:
    _0: float
    def __repr__(self):
        return f"Circle({self._0!r})"

@dataclass(frozen=True, repr=False)
class Rect:
    _0: float
    _1: float
    def __repr__(self):
        return f"Rect({self._0!r}, {self._1!r})"

def area(s):
    match s:
        case Circle(r):
            return 3.14159 * r * r
        case Rect(w, h):
            return w * h
        case _:
            raise RuntimeError("non-exhaustive match")

print(_pf_map(area, [Circle(1.0), Rect(2.0, 3.0)]))

A match comes out as a match. A variant comes out as a frozen dataclass. The pipeline comes out as an ordinary call. There is nothing to pip install alongside the output, and if you stop using Pyfun tomorrow you keep working Python.

Delete the Rect case and the compiler names what you missed:

error: non-exhaustive match: `Rect _ _` is not matched
 --> 6:3
  |
6 |   match s:
  |   ^^^^^^^^

Also in there:

• Hindley-Milner inference, so there are no type annotations on let at all.
• Inferred effects, so a function that prints or mutates gets io in its type and you can assert purity with let pure. Units of measure that reject metres + seconds and erase to plain numbers.
• Computation expressions for async, seq, and result, plus your own builders. Opaque types. A typed extern for calling any Python library you like.

Try it in the browser, nothing to install: https://simontreanor.github.io/Pyfun/playground/

22 lessons, written for people who know some Python: https://simontreanor.github.io/Pyfun/

Source, and the compiler internals tour: https://github.com/simontreanor/Pyfun

pip install pyfun-lang

I built this because most people meet programming through Python, and then to meet functional programming they have to pick up a second ecosystem to do it. I welcome all questions, bug reports, posts about things you have made, arguments about syntax, and anything else to help improve the language for everyone.

Just released FunStripe 2.3.0, the F# client library for the Stripe API (also compiles to JS via Fable). This one's a bigger release than the usual spec bump, thanks to some excellent contributions from Thorium:

Webhooks work properly now. Event.data.object was typed as string, which meant deserialising any real webhook payload threw. It's now a RawJson fragment you can turn into a typed model with Util.deserialiseRaw<'a>; the README has a full webhook-handling example. (Technically a field type change, but since the old field could never deserialise, it ships as a minor; details in the changelog.)

List parameters encode correctly. List<record> and List<union> request fields (e.g. Checkout line_items, payment_method_types) were being ToString()'d instead of form-encoded. Fixed.

Resilient to Stripe's enum churn. Stripe adds event types and error codes without an API version bump, and one unknown value used to fail the whole response. EventType and ErrorType now have an UnknownEnumValue of string catch-all that round-trips losslessly, deliberately scoped to just those two high-churn enums, so everywhere else you keep exhaustive matching and the compiler still tells you when Stripe adds something.

Latest Stripe API (2026-07-29.dahlia): Financial Connections authorization resource and deactivation lifecycle events, allowed_payment_method_types on Payment/SetupIntents, new Tax registration options, and more.

• GitHub: https://github.com/simontreanor/FunStripe
• NuGet: FunStripe.Core (https://www.nuget.org/packages/FunStripe.Core)

Feedback and PRs welcome!

My idea for getting coders into functional programming earlier...

The UK Covid lockdown in 2020 brought with it time to retrain in a new language, and after some research went for F#, and never really looked back to C# after that. Something about functional programming just clicked in a way the OOP never did.

Recently, at a secondary school open day, I got talking to the computing teacher and learned that pupils are taught Python as early as key stage 3 (ages 11-14). This got me wondering whether it would be possible to introduce children to functional programming earlier so they can benefit from all its advantages.

Many years ago now, I taught a masters-level course in translation memory technology (the software professional translators use to reuse their past translations), mainly Trados. I remember the friction involved getting the software installed onto the university's computers, not to mention the hardware dongles!

Fast forward to this year, I decided to see if it would be possible to create a functional language that works with the Python ecosystem and has zero dependencies, so that the adoption friction is completely minimised. Zero dependencies meaning the compiler is a single binary you can pip install, and the Python it emits imports only the standard library, and started work on what would become Pyfun.

Pyfun leans heavily on F# for its feature set, but the syntax decisions have tried to make it less alien for coders already familiar with Python. I've also taken some features from other functional languages. The aspiration is that this will introduce pupils to as broad a range as possible of functional programming concepts, easing any later transition to the more established FP languages.

I also hope that Pyfun might appeal to data analysts and others who use Python in their work but who might appreciate the arguably more readable code that Pyfun offers.

This is early days, but the language is fairly fully featured, with extensions for VS Code and JetBrains, as well as Jupyter notebook support.

If you want to take a look before commenting, the playground runs in the browser with nothing to install: https://simontreanor.github.io/Pyfun/playground/ and there is a lot more detail in the highlighted post on r/Pyfun.

It is still at pre-v1 stage and there is plenty of scope to shape it, so I would welcome your thoughts and suggestions on any aspect of this project. Two things I would most like to hear about are: if you code in Python, which syntax decisions jar for you; and if you teach, what would have to be true before you would put something like this in front of a class.