From Spec to Stripe: Building a Payment Provider for Xperience by Kentico

Over the past few months, I've been exploring how AI can genuinely speed up Xperience by Kentico development - not by replacing developers, but by cutting out the repetitive setup work that slows us down.

One of my recent experiments was using AI to create a Stripe payment provider for Xperience by Kentico.

It's a real world task that tested how far I could go using a spec-driven workflow, where AI tools like ChatGPT and Claude Code build from a clear plan instead of relying on vibe coding (and vague prompts that might come with it). 🤖

💳 Why Stripe?

Xperience by Kentico’s commerce features are flexible and extensible, making it easy to add new payment gateways. But with that flexibility, there can be a few additional steps required to set up and configure a payment gateway.

I've recently written about integrating Stripe with Umbraco in my recent post on Taking Stripe Payments in Umbraco Commerce. That article was focused on setting up Umbraco's demo site, installing their Stripe integration package, and wiring up the webhook to mark orders as paid.

However, this experiment built on that experience, but tackling it from a different angle. There isn't a vendor maintained package for Kentico and Stripe, so I wanted to see how far I could go in using AI to generate an equivalent. 💡

This new package should implement Stripe Checkout, help with handling Stripe webhooks, and have a core project that could be used for other payment integrations in the future.

🧾 Starting with a Spec

Before opening Visual Studio, I asked ChatGPT to help me draft a Markdown spec file which describes exactly how the Stripe payment provider should be structured.

I wanted to see if AI could do more than just code, but could it plan a full implementation the way a senior developer might?

It produced a surprisingly solid foundation, including:

  • ✅ Project details - name, target framework (.NET 8.0), nullable and XML docs enabled
  • 📁 Exact folder structure - /src, /tests, /samples, and even .github workflows
  • 📦 Package references - Stripe.net, XperienceCommunity.Commerce.PaymentProviders.Core, and common ASP.NET abstractions
  • 🧱 Key classes - StripeGateway, StripeOptions, and ServiceCollectionExtensions
  • 🧪 Unit tests and sample app - including a minimal hosted checkout and webhook handler
  • ⚙️ CI/CD setup - with a working GitHub Actions build and Dependabot config

You can see the full spec here, but here's just a snapshot of the beginning of the file:

# Stripe Provider Specification

## Project
- Name: XperienceCommunity.Commerce.PaymentProviders.Stripe
- Branch: feat/stripe-mvp
- Target Framework: .NET 8.0
- Nullable: enabled
- XML Docs: enabled
- External deps:
  - Stripe.net
  - Microsoft.AspNetCore.Http.Abstractions
  - XperienceCommunity.Commerce.PaymentProviders.Core [1.*,2.0)

---

## 1) Solution Structure (create exactly)
- /src/XperienceCommunity.Commerce.PaymentProviders.Stripe
- /src/XperienceCommunity.Commerce.PaymentProviders.Stripe/DI/ServiceCollectionExtensions.cs
- /src/XperienceCommunity.Commerce.PaymentProviders.Stripe/StripeOptions.cs
- /src/XperienceCommunity.Commerce.PaymentProviders.Stripe/StripeGateway.cs
- /tests/Stripe.UnitTests
- /tests/Stripe.UnitTests/WebhookTests.cs
- /tests/Stripe.UnitTests/CheckoutTests.cs
- /samples/MinimalHostedCheckout/Program.cs
- /.github/workflows/build.yml
- /.github/dependabot.yml
- /README.md
- /CHANGELOG.md
- /LICENSE

Notes:
- This MVP implements **hosted Stripe Checkout** and **webhook parsing**.
- The **host application** is responsible for idempotency storage and calling `IOrderPayments.SetStateAsync` based on parsed results (demonstrated in the sample).
- No provider-specific persistence inside the package.

---

## 2) Package References
Add to `src/XperienceCommunity.Commerce.PaymentProviders.Stripe/*.csproj`:
- `Stripe.net`
- `Microsoft.AspNetCore.Http.Abstractions`
- `XperienceCommunity.Commerce.PaymentProviders.Core` version `[1.*,2.0)`

This became the blueprint that I could then provide an AI agent, such as Claude Code, to implement.

🧭 What I Mean by "Spec-Driven"

There's been a lot of talk recently about Spec-Driven Development (SDD), especially frameworks like GitHub's Spec Kit, which help you create specs in a structured way that AI agents can act upon them.

What I’ve done here is a much simpler version of that idea - a spec-driven workflow, where I generated a spec with ChatGPT and handed it to Claude Code to implement.

It's the same principle, define first, generate second, just on a simpler scale.

The Result

Claude Code followed the spec file and created a decent first iteration of the package. It committed the changes, created a branch, and opened a Pull Request for me to review.

To test it, I set up a Dancing Goat sample application, put some coffee in my basket, went through to Stripe Checkout and successfully paid for my order.

Once I proxied the Stripe webhook requests through to my local website, it also started marking the orders in Kentico as fulfilled. 👏

Overall, the process proved that with the right structure, AI can handle the scaffolding work, freeing developers to focus on testing and refinement.

🚀 Now in Beta

I’ve now released the Stripe provider in beta (v0.1.0-beta), and you can access the source code in the GitHub repository.

I’d love feedback from other developers. Is it useful? Would you like to see it developed further?

Contributions are welcome too - feel free to open issues, share ideas, or submit a pull request! 💬

You might also be interested in