Skip to main content

Add a new payment processor alongside Stripe

Premium Advanced

Implement PodcastPaymentGateway and register your instance through the benecaster_payment_gateways filter. The filter is applied lazily, on first read rather than at plugin load, so registering from a benecaster_boot callback — or from file scope — both work.

is_test_mode(): bool is mandatory — a class missing it raises a PHP fatal at load (the interface declares it with no default body). Returning true makes the admin TEST MODE badge and subscriber-facing test-mode banner light up. Use benecaster_payment_test_mode_active() from your own templates to mirror Benecaster’s badge — it aggregates across every registered gateway and is safe to call before plugin boot (it returns false rather than fataling).

Test mode is resolved per show, not per install — a show with its own Stripe account can be live while the site default is test, or the reverse. Pass a show whenever you have one in scope:

// Subscriber-facing template with a show in scope.
if ( benecaster_payment_test_mode_active( $show_id ) ) { … }

// Admin chrome with no single show in view — the install default.
if ( benecaster_payment_test_mode_active() ) { … }

Showing “payments are not real” to a subscriber of a live show, because a different show happens to be in test, is worse than showing nothing at all.

Two asymmetries worth knowing, because neither is guessable from the interface.

1. The two call forms read different things, and only one of them can see your gateway. This is the asymmetry that matters most to a gateway author, because it is invisible in the signature — the show argument looks like a narrowing filter and is not:

Call What it reads Sees your gateway?
benecaster_payment_test_mode_active() every registered gateway, via PaymentTestModeManager::any_gateway_in_test_mode() Yes — your is_test_mode() is one of the votes
benecaster_payment_test_mode_active( $show_id ) StripeClient only, resolved from Stripe credentials No — never consults the registry

So your own gateway returning true makes the bare call true even when Benecaster’s Stripe is live — which is the correct and intended behaviour, and the reason the badge says “A payment gateway is running in test mode” rather than naming Stripe. Conversely, passing a show excludes your gateway entirely: the answer describes what Benecaster’s Stripe integration is doing on that show, which may not describe yours. A third-party gateway has no per-show mode dimension at all.

Do not read the bare call as “the install default”. It is not: it is a logical OR across gateways. If the Stripe install default is genuinely what you need, that is StripeClient::site_is_test_mode() and neither call form answers it.

2. Your gateway does not appear in the cross-show payment-mode banner. Reporting is_test_mode() === true still lights the TEST MODE notice and the subscriber-facing banner, as before. It does not put your gateway in the admin’s payment-mode banner, which names shows by their Stripe keysets. If your gateway needs to be visible there, raise it rather than working around it — that banner is the agreed mitigation for per-show mode, and its accuracy is load-bearing.

Code

<?php
add_filter( 'benecaster_payment_gateways', function ( array $gateways ): array {
    $gateways['benecaster_paypal'] = new PayPalGateway();

    return $gateways;
} );

class PayPalGateway implements \Benecaster\Payment\PodcastPaymentGateway {
    public function get_gateway_slug(): string { return 'benecaster_paypal'; }
    public function is_test_mode(): bool { return (bool) get_option( 'my_paypal_sandbox_mode', false ); }
    // … subscription lifecycle methods …
}

View on GitHub →

Hooks Used

Need this built rather than just documented? See our services →

Powered by