Skip to main content
Your custom plugin should implement the Monime payment adapter interface, and optionally the webhook adapter interface if you need to update your own records. The configuration you need depends on how much responsibility your plugin owns:
  • If your plugin only creates payments, the payment adapter is enough.
  • If your plugin also needs to update orders, donations, invoices, or membership records after payment, implement the webhook adapter too.
Monime’s bootstrap file loads the shared contracts and services first, then boots the platform integrations, shared adapter service, and webhook handler. Because of that, your custom integration should register its adapter from the main plugin file so Monime can discover it during plugin boot.

​
Payment Adapter

The payment adapter should provide:
  • An adapter ID.
  • A method for building the Monime payment payload.
  • Optional payment options and metadata.
The adapter ID should be unique across your site so Monime can identify which integration created the payment.

​
Webhook Adapter

If your plugin needs to process Monime webhook events, implement the webhook handler as well. This is where you convert a Monime payment event into your application’s internal state update. For example, you might mark an invoice as paid, activate a membership, or mark a donation as complete.

​
Payload Fields

The payment payload commonly includes:
  • line items,
  • idempotency key,
  • reference,
  • name,
  • description,
  • cancel URL,
  • success URL,
  • financial account ID,
  • currency,
  • payment options,
  • metadata,
  • callback state.

​
What These Fields Usually Represent

  • line items: what the customer is paying for.
  • idempotency key: a unique value that prevents duplicate payment creation.
  • reference: your internal payment or order reference.
  • name / description: text shown to the donor or customer in checkout.
  • cancel URL / success URL: where Monime should return the user after cancel or success.
  • financial account ID: optional settlement target inside Monime.
  • currency: the payment currency used for the checkout session.
  • payment options: the channels and provider restrictions you want to send to Monime.
  • metadata: any additional application data you want to carry through the payment flow.
  • callback state: extra state you want returned or preserved for post-payment handling.

​
Registration

Register the adapter from your main plugin file, before you create any checkout sessions. That is the safest place to load your adapter class and register it with Monime. Example pattern: 
<?php

use Monime\registry\AdapterRegistry;

require_once __DIR__ . '/includes/class-custom-monime-adapter.php';

add_action('plugins_loaded', function () {
    if (class_exists(AdapterRegistry::class) && class_exists(CustomMonimeAdapter::class)) {
        AdapterRegistry::registerAdapter(new CustomMonimeAdapter());
    }
});
This keeps registration close to the plugin bootstrap, which matches how Monime’s own integrations are loaded in monime_gateway.php.

​
Configuration Checklist

Before going live, confirm that:
  1. Your adapter class is required by the main plugin file.
  2. Your adapter registration runs during plugin boot, not only inside a request-specific class.
  3. Your adapter ID is unique.
  4. The payload includes the URLs Monime should return to.
  5. The reference maps back to a real object in your application.
  6. Your webhook handler can safely ignore duplicate webhook deliveries.
  7. Your plugin can recover from a payment that succeeds after the user closes the tab.