Select one or more tags, then press “Search Plugins”

Find Plugin with any / all of the selected criteria
Search Plugin

Gravity Forms EPC-QR Extension For Gravity PDF Wordpress Plugin - Rating, Reviews, Demo & Download

Gravity Forms EPC-QR Extension For Gravity PDF Preview Wordpress Plugin - Rating, Reviews, Demo & Download
No ratings yet
$25
Follow for free plugins, new theme releases and theme news

Plugin Description

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.

Reviews & Comments