Electronic invoicing, hardened.
WPFacturaE signs Facturae, submits to FACe and feeds VeriFactu from your WordPress store โ while your certificate stays encrypted and your private key stays out of WordPress, always.
How much safer is our flow?
The signer is a separate, auditable service. WordPress only ever holds an encrypted envelope โ the exact shape that lets the signer run in an AWS Nitro Enclave or similar trusted environment.
Upload
You export your .p12 and upload it in Ajustes. It is never written to disk in the clear.
Seal
WordPress encrypts it to the signer’s public key (WPFE1: RSA-OAEP wrapped key, AES-256-GCM payload). Only ciphertext is stored.
Sign
The signer unwraps the certificate in process memory, produces the signature, verifies it, and forgets โ nothing is cached, nothing is persisted.
Deliver
Signed Facturae XML, PDF with the official AEAT QR, and VeriFactu registros with CSV receipts come back out.
- Never persisted in the clear The .p12 exists on disk only inside a WPFE1 envelope encrypted with the signer’s public key.
- A WordPress breach leaks nothing usable The encrypted blob is meaningless without the signer’s private key, which WordPress never holds.
- The signer keeps no secrets at rest Decryption happens in memory for the length of a single request; no key material is written or cached.
- Auditable code The signer is a small, readable service that self-verifies every signature before releasing it.
- Verifiable, not just promised Run as a shared signer in an AWS Nitro Enclave, the cryptographic hash of its image proves exactly which code handles your data โ and that code stores nothing and does nothing beyond signing.
The leverage of a shared signer: one hardened instance, serving many stores, deployed as an AWS Nitro Enclave or similar trusted execution environment. Remote attestation publishes a cryptographic hash of the enclave image, so anyone can verify the exact audited binary before trusting it โ and by verifying the code, you verify the promise: the attested image neither stores nor processes the data fed to it beyond producing the signature.
One pipeline, end to end
From the WooCommerce order to the receipt at the public administration.
Facturae 3.2.2 + XAdES
Schema-valid XML and signatures shaped for FACe validation, with self-verification before release.
DIR3 intelligence
Official directory imports, unit NIFs, hierarchy lookups and OC-OG-UT relation triplets cached locally.
VeriFactu ready
RegistroAlta with the official huella chain, sandbox-proven responses and per-invoice CSV receipts.
PDF with AEAT QR
A printable rendition with the official VeriFactu QR code, generated on demand.
FACe & FACeB2B
B2G submission data and the FaceB2B extension for platform routing, built in.
Validation gates
Missing IBAN or incomplete party data blocks signing before a regulator ever sees it.
How it works
Five steps from checkout to receipt.
-
1
The order completes in WooCommerce and the plugin drafts a factura with the buyer data you configured.
-
2
You review the parties and DIR3 codes โ the autocomplete and relation finder fill the OC-OG-UT triplet for you.
-
3
You sign; the signer verifies its own output before anything leaves the service.
-
4
You export the signed XML or the VeriFactu-style PDF with the official QR.
-
5
You submit to FACe or register the record with VeriFactu, and keep the CSV receipt on the invoice.
Built by veterans of the field
Practitioners who have shipped production invoicing flows against the real constraints of Spanish administrations โ and wrote down what actually worked.
Talk to us
Tell us about your invoicing flow and we will get back to you.
This form opens your email client โ nothing is stored on the site.