Eventyay BitPay Plugin for Cryptocurrency Payments

What Eventyay BitPay Adds to Eventyay

Eventyay BitPay solves a specific payments problem for event organisers that want to accept cryptocurrency through BitPay or another provider that exposes a BitPay-compatible API. It is intended for organisers who already have a working Eventyay installation, rather than for people looking for a standalone cryptocurrency checkout system. The plugin adds a BitPay payment provider to Eventyay and places the connection inside the event's payment settings.

The project package is named `eventyay-bitpay`, while the Python module is named `eventyay_bitpay`. Its declared Python requirement is Python 3.9 or newer, and the README requires Eventyay 4.16.0 or newer. The plugin depends on `btcpay-python`. The repository metadata identifies the Eventyay team as author and maintainer, and the README describes the project as part of the Eventyay plugin ecosystem.

This is a payment integration, not a cryptocurrency wallet, exchange, accounting system, or general-purpose financial application. The buyer's payment is represented by an invoice created through the selected provider. Eventyay remains responsible for the order and payment records, while BitPay or the compatible provider handles the external payment interaction.

Installation for a Local Eventyay Environment

The documented installation path is development-oriented. It assumes that an Eventyay checkout and its virtual environment already work. Clone the plugin beside the Eventyay checkout or into the local plugin directory used by that setup, then install it in editable mode.

git clone https://github.com/fossasia/eventyay-bitpay.git
cd eventyay-bitpay

After cloning, activate the virtual environment associated with the Eventyay installation. The README gives this example path:

cd ../eventyay/app
. .venv/bin/activate

Install the plugin from the `eventyay-bitpay` directory. The README also documents an alternative for setups that use `uv`:

pip install -e .

uv pip install -e .

From the Eventyay app directory, apply migrations:

python manage.py migrate

The plugin's `Makefile` uses the `localecompile` target to run Django's message compilation command:

make

Then restart Eventyay development processes. For a local server, the documented command is:

python manage.py runserver

The README says that Docker-based Eventyay development environments should restart the relevant containers after installing or changing the plugin. It does not provide a Docker image, a production deployment manifest, or a complete production installation procedure, so those parts must come from the Eventyay deployment documentation.

Configuring BitPay and Compatible Providers

Configuration begins in the Eventyay organiser interface. Open the event, enter its payment provider settings, enable the BitPay provider, and connect the event to BitPay, `test.bitpay.com`, or a compatible API. The settings also allow organisers to define a custom public payment method name.

The plugin distinguishes between connection with BitPay and connection with `test.bitpay.com`. The README states that test mode does not transfer real money and recommends using it before enabling cryptocurrency payments for a live event. For another provider, the organiser enters its API URL and starts pairing. The exact credential fields and pairing screens are not documented in the repository README, so an integrator should expect to follow the event's existing payment settings flow rather than assume a separate configuration schema.

After the BitPay token is authorised, the README instructs the organiser to return to Eventyay and refresh the payment provider settings page. This token-based pairing step is a meaningful boundary. The plugin can connect to an external service, but it cannot process payments until the selected provider returns the authorisation required by the integration. The documentation does not explain token expiration, revocation, multi-account selection, or the behavior of every BitPay-compatible implementation.

Checkout Invoices, Returns, and Webhooks

The checkout flow starts when the plugin creates a BitPay invoice for the order payment amount and the event currency. The payment provider returns an invoice URL, and the buyer is redirected to that URL. The plugin stores invoice data with the Eventyay order payment and records the external BitPay invoice reference.

After the buyer completes payment, Eventyay receives a return through an event-specific URL. Separately, the plugin exposes a webhook endpoint for provider notifications. When a webhook arrives, the plugin looks up the referenced BitPay object, verifies that it belongs to the current event, logs the BitPay event, and processes the invoice status.

The documented invoice states are `new`, `paid`, `confirmed`, `complete`, `expired`, and `invalid`. Invoices in the `paid`, `confirmed`, and `complete` states can confirm the Eventyay payment. An unpaid invoice produces a pending payment view rather than a completed Eventyay payment. This state mapping is the central mechanism behind reconciliation between an external provider and the event's internal order payment.

The event routes documented by the README are:

/<organizer>/<event>/bitpay/webhook/
/<organizer>/<event>/bitpay/redirect/
/<organizer>/<event>/bitpay/return/<order>/<hash>/<payment>/

The control routes for connecting and disconnecting are:

/control/event/<organizer>/<event>/bitpay/connect/
/control/event/<organizer>/<event>/bitpay/disconnect/

The README does not document webhook signature verification settings, retry expectations, ordering guarantees, or a command for replaying missed notifications. Those details need confirmation from the implementation and the selected provider before relying on automatic reconciliation.

Refunds and Referenced BitPay Objects

The plugin supports both refunds and partial refunds through the BitPay-compatible API. If the provider reports an error while processing a refund, the plugin raises an Eventyay payment exception. According to the README, that exception lets the organiser see that the refund could not be completed automatically. The repository does not specify whether the failed operation is retried, placed in a background queue, or reconciled later, so operators should not assume that every provider error receives automatic recovery.

Its `ReferencedBitPayObject` model stores references to external BitPay objects. Each reference is linked to an Eventyay order and, when available, an Eventyay payment. This association lets webhook notifications map back to the corresponding order and payment rather than treating an external invoice as an isolated transaction.

The model is therefore part of the integration's reconciliation design. It supports return handling, webhook processing, and payment confirmation, but the README does not describe retention periods, deletion behavior, or how duplicate notifications are handled. The phrase “payment data shredding” in the feature list refers to handling sensitive payment information, but the README does not specify the exact fields affected or the implementation. Organisers with strict data-handling requirements should inspect the Django model and plugin code rather than relying on that feature name alone.

Maintenance, Packaging, and Licence Boundaries

The repository is not archived, and its last push was on 2026-09-29. That is the maintenance fact available from the repository metadata, and no GitHub releases are listed. The absence of releases means there is no documented release cadence or versioned upgrade path in the repository metadata. The package version is declared dynamically from `eventyay_bitpay.__version__` in `pyproject.toml`, so the actual installed version should be checked from the Eventyay environment.

The repository includes `pyproject.toml`, `setup.py`, `Makefile`, `README.rst`, `LICENSE`, and the `eventyay_bitpay/` package. It also declares setuptools and `pretix-plugin-build` as build requirements, plus `btcpay-python` as a runtime dependency. Translation files can be compiled with `make` and regenerated with:

make localegen

The README says tests can be run if tests are present in the checkout:

pytest

The repository's licence is classified as Other because GitHub cannot map it to a standard licence identifier. The `LICENSE` file must be read before redistribution or deployment. This review does not interpret the legal terms or provide legal advice. It also cannot establish whether a particular compatible provider is compatible beyond its API claim, or whether a deployment's dependency versions remain compatible after an Eventyay upgrade.

A real alternative is a payment provider integrated directly with Eventyay without BitPay compatibility. Such an integration can avoid the BitPay invoice and token-pairing model if its provider offers a native Eventyay payment method, but it may not support the same compatible-provider approach or cryptocurrency network. The choice depends on provider support and Eventyay integration requirements, not on the plugin's feature count.

Editorial conclusion

Adopt Eventyay BitPay when the organiser already operates Eventyay 4.16.0 or newer and can obtain BitPay or compatible API credentials. Do not choose it without a working Eventyay environment, a payment account, and a plan for provider-specific API behavior. Verify the Python version, Eventyay version, provider URL, test-mode pairing, webhook routing, and custom LICENSE terms before enabling it for a live event.

Frequently asked questions

Official sources

1. fossasia/eventyay-bitpay on GitHub
2. Issues
3. README