Gravity Forms EPC-QR for Gravity PDF — Your Invoice, Paid With One Scan

Adds a payment page to the PDF your form already produces: a real EPC QR code that any European banking app reads, with beneficiary, IBAN, amount and payment reference prefilled. The customer scans, confirms, and the invoice is paid.

No typing, no transposed digits, no “which account was that again”. The payment details are printed underneath the code as well, so the page also works for someone without a banking app — and so a wrong value becomes visible instead of staying hidden inside a square of dots.

Why you’ll love it

A real EPC QR code, following EPC069-12 for SEPA credit transfers — the same standard the banking apps of the euro area implement. Beneficiary, IBAN, BIC, amount, purpose and reference travel inside it, exactly as the specification prescribes.
Appended to any Gravity PDF. The invoice your template produces stays untouched; the code arrives as a further page at the end. Every PDF of a form, or just the one you pick.
The amount comes from the entry, not from a second field somebody has to keep in sync — it is the same order total Gravity Forms shows. The code can never ask for a different sum than the invoice states.
Invoice number and date through merge tags. Write the tags your document already uses, and whatever produces them reaches the payment reference — this plugin never needs to know the source.
⚙️ One shared settings page for the whole family. Company name, IBAN, BIC and creditor reference are entered once and are readable by every companion add-on. No IBAN typed twice, so no two IBANs — company name and IBAN are required specifically for this add-on, since an EPC QR code cannot exist without them.
️ An outage never breaks an invoice. Only a value that definitely cannot work stops the page; a malformed BIC costs that one field, not the document. A PDF produced while a notification is being sent can never fail because of a payment code.
Nothing to install. The payload library ships with the plugin, and the QR encoder comes from Gravity PDF itself. No Composer step, no API key, no external service — the code is computed on your own server.
Translation-ready. English and German included, fully internationalized.

Key features

The payment page

A heading and a short introduction, configurable per feed and both merge-tag aware.
The QR code, 45 mm square, error correction level M — comfortably scannable from a printed invoice.
A list of the values that actually went into the code, generated from the payload’s own record of what it encoded rather than from the settings. It therefore cannot claim something the code does not contain. Switchable per feed.
The page carries its own margins, so it looks the same whichever invoice template it is appended to — and the indent is only ever added to what the template already provides, so a document with generous margins never ends up doubly indented. Adjustable through one filter.

Reference or text — the standard’s rule, made usable

The EPC standard allows either a structured creditor reference or unstructured remittance text. Never both. Instead of failing at that, the feed offers the choice: the reference when one is configured, always the reference, or always the text. When the automatic mode picks one over the other, the decision is written to the log — so it stays explainable later instead of mysterious.

Seven purpose codes

The ISO 20022 purpose codes that matter for invoicing, from supplier payment to tax payment, salary and pension.

The shared “(e)invoice Settings” page

Every add-on of this family that needs global configuration would otherwise add its own tab. Five add-ons, five tabs, and the same company IBAN typed into three of them. Instead there is one page, built from a shared field catalogue — a plugin no longer defines a field, it requests the ones it needs, and a field several plugins name still appears exactly once. This one requests the company name, IBAN, BIC and creditor reference, and marks company name and IBAN required for itself specifically — since an EPC QR code cannot exist without them, while the company’s other companion add-ons are perfectly valid without a payment account. Your own plugin can request a catalogue field, or add its own section, with a single call:

EInvoicePress_Fields::init();

EInvoicePress_Fields::request( array(
    'en16931_seller_name',
    'en16931_seller_iban',
) );

Read a value from anywhere with EInvoicePress_Settings::get( ‘en16931_seller_iban’ ). A field your plugin needs alone can still be contributed as its own section:

add_filter( 'einvoicepress_settings_sections', function ( $sections ) {

    $sections[] = array(
        'title'    => 'My Section',
        'priority' => 20,
        'fields'   => array(
            array( 'name' => 'my_plugin_value', 'type' => 'text', 'label' => 'My value' ),
        ),
    );

    return $sections;
} );

The identifiers are validated, not just stored

IBAN — check digits and per-country format.
BIC / SWIFT — length, structure and a real ISO 3166-1 country check at positions 5-6.
Creditor Reference — structure plus the ISO 7064 MOD 97-10 check digits of ISO 11649.

A typo is caught while it is being saved, not months later by a payment that never arrives. These are the portable Settings API field types of the companion SEPA Fields add-on, copied in as self-contained packages — same rules, same messages, no dependency between the plugins.

Checked before you configure it

The feed screen names what is missing rather than letting you discover it from an invoice that went out without a code: wrong currency, Gravity PDF inactive, no PDF on this form, or company name and IBAN not entered yet — both required fields on the settings page. The very same checks run at render time, so the two can never disagree about what is wrong.

Built for how Gravity PDF actually works

A Gravity PDF document is not built when the form is submitted — it is built whenever somebody asks for it, possibly years later and several times over. The page is therefore produced at render time, which is the only point at which the finished document exists. Gravity PDF reuses files it has already saved, so a document created before you added the feed keeps its old content; one feed switch rebuilds it, off by default so nothing slows down in normal operation. And a document is never extended twice, however often the hooks fire within a request.

What’s included

The plugin — a Gravity Forms feed add-on for Gravity PDF, plus the shared (e)invoice Settings page other plugins can extend.
The smhg/sepa-qr-data payload library, bundled. No Composer step.
Portable iban, bic and iso11649 Settings API field types with their dependency-free validators — reusable in your own plugins.
English and German translations (.po / .mo).
Full documentation in English and German (README + feature overview), including the developer reference and every hook.
Clean, well-structured, object-oriented and heavily commented code — easy to read, extend and audit.

Requirements & compatibility

WordPress with Gravity Forms ≥ 2.5
Gravity PDF ≥ 6 (the free core plugin is enough)
PHP ≥ 8.1
The Gravity Forms currency has to be EUR — the EPC QR standard supports no other
No outbound network access, no API key, no third-party service
Works alongside the companion SEPA Fields, VAT ID Field, SIRET Field, LEI Field and ABN Field add-ons.

Support & updates

Clean, well-documented code that’s easy to maintain. Localization-ready out of the box. Built to follow Gravity Forms’ official add-on framework and Settings API conventions and to use Gravity PDF’s documented filters, so it stays compatible as your stack evolves.

Changelog

1.0.1

The beneficiary block moved into the shared field catalogue, so its fields are requested — not redefined — by every add-on of the family that needs them.
Company name and IBAN are now required fields, enforced on the shared settings page specifically for this add-on.
Values stored under the pre-1.0.1 field names are carried over automatically, once.

1.0.0

Initial release. Feed add-on that appends an EPC QR payment page to a Gravity PDF document.
The shared (e)invoice Settings page, extensible by any plugin through one filter.
Beneficiary block with validated IBAN, BIC and creditor reference, using the portable Settings API field types of the SEPA Fields add-on.
Amount taken from the entry’s order total; purpose code, remittance reference or text, and payer information per feed, with merge tag support.
Structured reference and unstructured text are mutually exclusive per the standard; the feed makes the choice instead of failing at it.
Own page margins, adjustable through the sp_epcqr_page_margins filter.
Optional rebuild of already saved PDFs.
German translation.

SP Gravity Forms EPC-QR Extension for Gravity PDF WordPress Plugin