Laravel SDK for Rapyd payments - full API coverage with Facade, webhooks, and typed DTOs

Rapyd is a fintech-as-a-service platform (payments, payouts, wallets, card issuing, KYC) but has no official Laravel package. I built one.

**saba-ab/rapyd** — a Laravel package wrapping the full Rapyd API with a clean Facade, resource-based architecture, webhook handling, and typed DTOs.

// Create a payment
$payment = Rapyd::payments()->create([
'amount' => 100,
'currency' => 'USD',
'payment_method' => ['type' => 'us_visa_card', 'fields' => [...]],
]);

// Webhook verification is automatic on the registered route

What's included:

* `Rapyd::` Facade with fluent resource accessors (payments, refunds, customers, checkout, subscriptions, payouts, wallets, cards, KYC, fraud)
* HMAC-SHA256 request signing handled internally
* Auto-registered webhook route with signature verification
* Config-driven sandbox/production switching
* Built on `spatie/laravel-package-tools`
* Artisan commands: `rapyd:test-connection`, `rapyd:list-payment-methods`
* PHP 8.2+, Laravel 11/12/13

Install: `composer require saba-ab/rapyd`

GitHub: [https://github.com/saba-ab/rapyd](https://github.com/saba-ab/rapyd)

I also built a Python SDK covering the same API surface (`rapyd-py` on PyPI) and an MCP server is in the works.

https://redd.it/1se7au8
@r_php

PHP developers who stream on Twitch?

There is a post about this already but its from years ago.

"I was wondering if there are any developers from the PHP/Laravel world who stream on Twitch (or any other platform) on a regular basis. I don't necessarily mean core developers, but developers of more or less well-known packages or extensions."

For personal reasons I can't code right now but it would be awesome to follow along someone building a project live :) I would love some recomendations. Thanks!

https://redd.it/1sedh7o
@r_php

I built a Redis-based alternative to Laravel permission systems (140+ installs) – looking for feedback

Hey everyone 👋

I’ve been working on a Redis-based alternative to traditional Laravel permission systems.

The idea is to avoid hitting the database on every permission check and improve performance in high-traffic apps.

It currently has 140+ installs, and I’d really appreciate feedback from people running Laravel at scale.

Repo:

https://github.com/scabarcas17/laravel-permissions-redis

Curious how you all handle permissions in larger applications 🤔

https://redd.it/1sedxwp
@r_php

I built a framework to turn Laravel + Livewire apps into desktop & mobile apps using PHP WebAssembly, no Electron, no React Native

Hey everyone,

I've been working on a side project called NativeBlade and wanted to share it with the community.

The idea is simple: take your Laravel + Livewire app and run it as a native desktop or mobile application. No server needed. No Electron. No JavaScript frameworks. Just PHP and Blade.


How it works

Your entire Laravel application gets bundled and runs inside a PHP WebAssembly runtime, wrapped in a https://v2.tauri.app shell. The architecture looks like this:


\- PHP 8.3 runs in the browser via WebAssembly

\- Blade templates and Livewire components work as-is

\- SQLite database persists to IndexedDB (survives app restarts)

\- Native shell components (header, bottom nav, drawer) render outside the WebView — no flicker during navigation

\- Native OS features (dialogs, notifications, system tray) work through a bridge


The whole thing started as a weekend experiment: "what if I could just composer require something and turn my Laravel app into a desktop app?"


What it can do


\- Desktop: Windows, macOS, Linux with native menus and system tray

\- Mobile: Android & iOS with status bar, safe area, swipe back

\- External HTTP requests: Http::get() works transparently through a JS bridge — PHP signals what it needs, JavaScript makes the real fetch, PHP re-executes with the cached

response. You can even use NativeBlade::pool() to run multiple requests in parallel via Promise.all()


\- 1,512 built-in icons from https://phosphoricons.com/ — works in both shell components and Blade templates

\- Hot reload during development via a Vite plugin that watches PHP/Blade files

\- Offline-first — everything runs client-side, no internet required after install


That's it. Your Laravel app is now a desktop application.


What doesn't work



I want to be upfront about the limitations. Since PHP runs in WebAssembly, there's no real server:


\- No queues/jobs — no background worker process

\- No mail — no SMTP from WASM

\- No MySQL/Postgres — SQLite only

\- No sessions — uses a built-in state management instead

\- No cron/scheduling

\- Http::get() works but through a bridge (not native PHP networking)



It's not meant to replace server-side Laravel. It's for apps that run locally and don't need a backend, think tools, dashboards, utilities, offline apps.



Why I'm sharing this


This started as a learning project and I'd love to get feedback from the PHP community. The codebase touches a lot of interesting areas:


\- PHP WebAssembly internals

\- Tauri 2 (Rust-based alternative to Electron)

\- Livewire's lifecycle inside a non-standard runtime

\- Bridging sync PHP with async JavaScript


If any of this sounds interesting to you — whether you want to contribute, experiment, or just tell me what I'm doing wrong — I'd appreciate it.


GitHub: https://github.com/NativeBlade/NativeBlade



Happy to answer any questions!

https://redd.it/1seip9s
@r_php

What does your PHP stack actually look like in 2026?

I've been building PHP applications professionally for 10+ years, and I'm curious what everyone here is using these days.

Our current stack at work:

* PHP 8.3 + Laravel
* Vue.js on the frontend
* MySQL + Redis for caching
* Docker for local dev and deployments
* GitHub Actions for CI/CD
* AWS for hosting

We've tried moving parts to Node.js a couple of times, but honestly, we keep coming back to Laravel for anything business-critical. The ecosystem is just too mature and productive to give up.

A few things I've noticed in 2026:

* PHP 8.3 JIT is genuinely fast now; the performance gap with Node is much smaller than people think
* GraphQL adoption in PHP projects has grown a lot
* Redis has basically become a default part of every stack

Curious what others are doing, are you still on Laravel or have you moved to Symfony, Slim, or something else entirely? Anyone running PHP in a microservices setup with Docker and Kubernetes?

Drop your stack below 👇

[**https://mamotechnolabs.com/blogs/modern-php-tech-stack-2026**](https://mamotechnolabs.com/blogs/modern-php-tech-stack-2026)

https://redd.it/1senu9l
@r_php

PHP + Go ? An execution layer for web apps

A friend of mine has been working on an app called Doki (Github: imranscripts/doki) that turns prompts into runnable apps, and one design choice I found interesting was using Go for the execution layer.

Some parts of the system need to run a lot of tasks in parallel (for example Playwright tests across multiple apps/environments). Instead of keeping everything in the main stack (PHP), he introduced a small Go service to handle execution.

From what I’ve seen, it works well because:

* goroutines make it easy to run many workers concurrently
* low overhead when spawning parallel jobs
* straightforward worker pool patterns
* good fit for orchestrating external processes (Playwright, Docker, etc.)

The Go service which is in its own container basically acts as an execution engine:

* receives jobs (test runs, tasks, etc.)
* distributes them across workers
* manages process lifecycle and isolation

It seems like a clean way to separate orchestration from the main app while keeping performance predictable under load.

Curious if others here are using a similar pattern (mixing PHP with Go, or Node with something like Rust/Go) for parallel execution workloads.

https://redd.it/1seo01e
@r_php

🚀 I built a self-hosted visual workflow automation tool for Filament (Voodflow)
https://redd.it/1seqhfc
@r_php

More dependency considerations
https://stitcher.io/blog/more-depedency-considerations

https://redd.it/1seqojs
@r_php

More dependency considerations
https://stitcher.io/blog/more-depedency-considerations

https://redd.it/1ser8uy
@r_php

Laravel Nestedset: Effective tree structures for SQL databases

The new 7.3 version of the aimeos/laravel-nestedset package for managing trees using nested sets improves performance. It's an highly optimized version of the popular kalnoy/nestedset package which, unfortunately, has been virtually abandoned by its owner.

- Repo: https://github.com/aimeos/laravel-nestedset

The 7.3 release contains:
- Reduced number of queries
- Possibility to create own indexes
- Option to avoid model firing events on recusive deletion
- Optimized PHP code
- Improved indexes

To dig deeper into the package, please check:

- https://laravel-nestedset.org
- https://github.com/aimeos/laravel-nestedset

If you like the package, leave a star :-)

https://redd.it/1sermgu
@r_php

I built an Inertia.js bundle for Symfony

Hey,

I've been working on nytodev/inertia-bundle, a Symfony bundle that implements the Inertia.js server-side protocol, basically the Symfony equivalent of inertia-laravel.

What it does:

Full Inertia.js protocol (XHR visits, partial reloads, asset versioning, 302→303 redirects)
All prop types: optional(), always(), defer(), once(), merge(), deepMerge()
SSR support via HTTP gateway
Symfony 6.4 / 7.x / 8.0 compatible, PHP 8.1+

Note: This bundle targets Inertia.js v2. v3 support is in progress.

GitHub

Packagist



https://redd.it/1sevcz8
@r_php

🎊 SymfonyLive Paris 2026 : le wrap-up ! 🚀
https://symfony.com/blog/symfonylive-paris-2026-le-wrap-up?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

https://redd.it/1sewmib
@r_php

Scythe: an SQL Compiler and Linter, making ORMs redundant

Hi Peeps,

I released Scythe — an SQL compiler that generates type-safe database access code from plain SQL. If you're familiar with sqlc, the concept is similar — sqlc was a direct inspiration. Since Scythe treats SQL as the source of truth, it also ships with robust SQL linting and formatting — 93 rules covering correctness, performance, style, and naming conventions, powered by a built-in sqruff integration.

## Why compile SQL?

ORMs add unnecessary bloat and complexity. SQL as the source of truth, from which you generate type-safe and precise code, gives you most of the benefits of ORMs without the cruft and hard-to-debug edge cases.

This is common practice in Go, where sqlc is widely used. I personally also use it in Rust — I used sqlc with the community-provided Rust plugin, which is solid. But sqlc has limitations: type inference for complex joins, nullability propagation, and multi-language support are areas where I wanted more.

## What Scythe does differently

Scythe has a modular, trait-based architecture built in Rust. It uses engine-specific manifests and Jinja templates to make backends highly extensible. Out of the box it supports all major backend languages:

- Rust (sqlx, tokio-postgres)
- Python (psycopg3, asyncpg, aiomysql, aiosqlite)
- TypeScript (postgres.js, pg, mysql2, better-sqlite3)
- Go (pgx, database/sql)
- Java (JDBC)
- Kotlin (JDBC)
- C# (Npgsql, MySqlConnector, Microsoft.Data.Sqlite)
- Elixir (Postgrex, MyXQL, Exqlite)
- Ruby (pg, mysql2, sqlite3)
- PHP (PDO)

It also supports multiple databases — PostgreSQL, MySQL, and SQLite — with more planned.

Most languages have several driver options per database. For example, in Rust you can target sqlx or tokio-postgres. In Python, you can choose between psycopg3 (sync), asyncpg (async PG), aiomysql (async MySQL), or aiosqlite (async SQLite). The engine-aware architecture means adding a new database for an existing driver is often just a manifest file.

Beyond codegen, Scythe includes 93 SQL lint rules (22 custom + 71 via sqruff integration), SQL formatting, and a migration tool for sqlc users.

- GitHub
- Documentation
- crates.io


https://redd.it/1seurw1
@r_php

Follow-up: Filament Compass

Hey everyone,

Earlier this week I posted about a repo I made called Filament Compass, which provides structured data to stop AI from hallucinating or using deprecated methods when generating code for Filament v5.

I wanted to drop a quick update: I've launched filament-compass-pkg, so you can now install this data directly into your projects via Composer!

Just to clarify how the two repositories work together:

The original repo remains the main source of truth. You can still use it to create your own custom "compass" or even refine the base data to better suit your needs.
The new pkg repo is the "result" repository that acts strictly as the provider for Composer/Packagist.

I sync the data manually between them using a script available in the main repo. If you want to run the script yourself or customize it, just drop the source repositories (filament, demo, filament-compass-pkg) into the source folder of the main repo, and update the sync.sh (and/or PLAN.md) file if you introduce any new folder structures or instruction update.

Installation & Documentation:

You can find the setup instructions in the README of the new package repo: https://github.com/aldesrahim/filament-compass-pkg

Note:
The new package is not tested thoroughly yet, but I've checked that Claude Code can successfully read the filament-compass skill and its documentation.

Let me know what you think, and happy coding!

https://redd.it/1sf21bu
@r_php

A different approach to PHP debugging
https://ddless.com/blog/technical-journey-building-php-debugger

https://redd.it/1sf4foa
@r_php

SymfonyLive Berlin 2026: Discover the Workshops!
https://symfony.com/blog/symfonylive-berlin-2026-discover-the-workshops?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

https://redd.it/1sf3dc5
@r_php

PHP Tek Returns to Chicago May 19-21, 2026



Hi PHPers... come join us for 3 days of fun, networking, and learning. PHP Tek is the longest running PHP conference and is returning for our 18th annual show.

This year we will have our 3 normal tracks for PHP Tek, plus a 4th track dedicated to JavaScript presentations.

Use this link to get $100 off your ticket.


https://ti.to/phptek/phptek-2026/discount/reddit

https://redd.it/1sf5ptx
@r_php

👻 PHP Dead Code Detector is stable (after 4 years of development), newly supports even Laravel!
https://github.com/shipmonk-rnd/dead-code-detector

https://redd.it/1sfr3n7
@r_php

Feedback on my package Laravel Policy Engine

Hey gang,

I've been building a larger project but one of the most complex parts of it has been authorization. I really spent a lot of time thinking through the authorization model and wanted something like IAM policy documents but native to my Laravel app.

I am a long time Spatie fanboy and have used Roles & Permissions package for years, but for this particular build I'm working on, I don't think the data model was quite granular enough in the way I'm needing.

So over the last couple months I've been building Laravel Policy Engine which has been everything I've learned while working on my larger app. I've really tried to distill it down and harden it into a rock solid package.

The pitch is basically,

1. Declarative policy documents your entire authorization config lives in version-controlled JSON.
2. Scoped permissions roles are assigned per-scope (team::5, plan::pro), not just globally. One user can be an admin in one org and a viewer in another, without workarounds and such. Just declare it and it just works.
3. Permission boundaries, hard ceilings per scope, like AWS permission boundaries. Even if someone holds admin, the boundary has final say.
4. Deny rules rule everything, so !posts.delete overrides every allow, across every role. No "last role wins" ambiguity.
5. Wires into Laravel's Gate, so $user->can(), @can, authorize(), and can: middleware all just work.
6. Interface driven so every component is an interface. Swap the Eloquent stores for DynamoDB, swap the evaluator for a remote policy service, whatever. The API basically never changes.

Define your authorization as declarative JSON documents and import them the way you'd manage AWS IAM policies:

{
  "version": "1.0",
  "permissions": [
    "posts.read",
    "posts.create",
    "posts.update.own",
    "posts.delete.any"
  ],
  "roles": [
    {
      "id": "editor",
      "name": "Editor",
      "permissions": [
        "posts.read",
        "posts.create",
        "posts.update.own",
        "!posts.delete.any"
      ]
    }
  ],
  "boundaries": [
    {
      "scope": "plan::free",
      "max_permissions": ["posts.read", "comments.read"]
    },
    {
      "scope": "plan::pro",
      "max_permissions": ["posts.*", "comments.*", "analytics.*"]
    }
  ]
}

I've really tried to put this thing through the ringer so any feedback would be very welcomed. Worst case it will have a userbase of 1 (me haha) but if it's helpful to anyone else I wanted to share.


https://redd.it/1sg2zym
@r_php

C-level APCu key isolation based on FPM pool names (Zero-allocation)

Hey everyone,

APCu is arguably the best in-memory key-value store for single-node PHP applications. It’s blazingly fast because it runs within PHP's own master process. But it has one massive, well-known architectural flaw in multi-tenant environments: It lacks pool isolation.

If you run multiple independent applications on the same server, each in their own PHP-FPM pool (with their own system users), they still share the exact same APCu memory segment. Pool A can read, modify, or delete Pool B's keys.

The standard solution is relying on PHP developers to manually prefix their keys (e.g., $cache->set('app1_config')). Not only is this annoying to maintain, but it offers zero security if an application gets compromised—a malicious script can just iterate and modify out the neighbor's cache.

I decided to fix this at the C level.

I wrote a patch for the APCu extension that introduces a transparent memory hook. It automatically namespaces every cache key based on the active PHP-FPM pool, completely invisible to the PHP userland.

How it works under the hood (The C Magic):

Instead of allocating new heap memory (malloc/free) on every web request—which would destroy APCu's legendary speed—I engineered a zero-allocation memory reuse strategy:

Out-of-Band Pool ID: When an FPM worker spawns, the C code reads /proc/self/cmdline to safely extract the exact pool name (falling back to geteuid() if procfs is restricted).

Worker-Lifetime Persistence: On the worker's very first APCu call, it allocates a single, persistent zend_string buffer (default 256 bytes) that survives the request shutdown and is immune to PHP's garbage collector.

Raw memcpy & Zend Spoofing: On every subsequent cache request, the code uses a fast memcpy to drop the user's requested key directly into this persistent buffer right after the static pool prefix. It then mutates ZSTR_LEN and forcefully resets the hash (h = 0) to trick APCu into recalculating the hash for the new, secured string.

The Result:

A script in Pool A calls apcu_store('db_config', $data). Pool B calls the exact same thing. In physical RAM, they are securely locked away as pool_A_db_config and pool_B_db_config. No application intervention required. Zero performance penalty.

I've documented the exact architecture, installation instructions, and how to maintain the patch on future APCu releases.

GitHub Repo: https://github.com/Samer-Al-iraqi/apcu-fpm-pool-isolation

I'd love to hear feedback from other extension developers or anyone dealing with shared-hosting/multi-tenant PHP architectures!

https://redd.it/1sg9rln
@r_php

Flow PHP PostgreSql Symfony Bundle
/r/PHP/comments/1sfmlha/flow_php_postgresql_symfony_bundle/

https://redd.it/1sfmlwt
@r_php