---
title: Automatic invoices with Fakturownia and inFakt
description: How to connect your own Fakturownia or inFakt account, what lands on the invoice Insy creates for each sale, and the cases where no invoice is created at all.
---
Insy can push an invoice into **your own** Fakturownia or inFakt account when a sale goes through.
The document is created under your account, numbered by your provider, and Insy keeps only the
number and — for Fakturownia — a link to the PDF.
This is about the invoices **you** issue to **your buyers**. It is not the commission invoice Insy
issues to you for platform fees; that one is produced by Insy and has nothing to do with this
integration.
## What you need before it can work
> **Without business information, no invoice is ever created**
>
> Two things must be true at the moment of the sale: the money went through a **connected Stripe
> account**, and that Stripe account has **business information** saved. If the business information
> is missing, invoice generation stops silently — no invoice, no error on the integration card, no
> email. Fill it in before your first sale, not after.
Business information is stored **per Stripe account**, not per community — so every community and
product that sells through the same Stripe account shares one record. You edit it on the Business
information screen of a community or a product, or on the Stripe account itself under your account
settings.
The fields:
- **Customer type** — individual or company. Required, and it decides which of the fields below you
can even see.
- **NIP** — required, and only shown, when you pick company.
- **Buyer** — the name. Required.
- **Street**, **Postal code**, **City** — all required.
- **VAT rate** — optional whole number from **0 to 23**. Only shown when you pick company.
> **The field says buyer, the invoice says seller**
>
> The record is labelled *Buyer* because Insy also uses it as your details on its own commission
> invoice. On an invoice created through this integration the same values are sent as the **seller** —
> name, NIP, street, postal code and city. Fill it in as the business doing the selling.
## Connecting a provider
Both providers live on the **Integrations** screen of a community, and on the Integrations screen of
a digital product. Each has a card — Fakturownia, inFakt — with a **Connect** button that opens a
short form. After saving, that button becomes **View**; the dialog it opens shows whether the
provider has rejected anything, and a **Reconfigure** button inside it brings the form back.
> **One connection per community or product**
>
> The integration is attached to a single community or product. There is no account-wide setting, so
> every community and every product you sell has to be connected on its own.
**Fakturownia**
Two fields, both required.
**API Key** — an API token from your own Fakturownia account. Insy sends it as `api_token` in
the body of the request that creates the invoice.
**Fakturownia subdomain** — the part before `.fakturownia.pl` in your account's address. For
`mycompany.fakturownia.pl` you enter `mycompany`. Insy posts to
`https://your-subdomain.fakturownia.pl/invoices.json`, so a typo here is the same as a wrong
key.
**inFakt**
One field.
**API Key** — an API key from your own inFakt account. Insy sends it in the `X-inFakt-ApiKey`
header to `https://api.infakt.pl/api/v3`, and no other value is stored: the seller details on
the invoice come from your inFakt account, not from Insy.
Insy does not link to your provider or explain where the key is generated — you create it in the
provider's own panel and paste it in.
> **Nothing checks the key when you save it**
>
> Saving only stores the string. Insy makes no test call, so a wrong key, a revoked key or a mistyped
> subdomain looks exactly like a working setup — the card says the integration is active. You find out
> at the first sale, once an invoice has already failed to be created.
## Fakturownia always wins
Both keys fit in the same record, and both cards will happily show themselves as connected. But
Insy picks the provider by looking at the Fakturownia key first: **inFakt is only used when the
Fakturownia key is empty**.
There is no provider switch and no **Disconnect**. The API has no delete for this integration, and
both forms refuse an empty key — so once a Fakturownia key has been saved, there is no way from the
interface to clear it and fall back to inFakt.
## When an invoice is created
Exactly two moments, both on the Stripe rail:
- **The first payment of a subscription** — when the subscription checkout completes.
- **A one-time payment** — both the hosted checkout in payment mode and the embedded checkout's
successful payment.
Insy keys the invoice to the payment, so a payment can never produce two invoices.
> **Nothing else creates an invoice**
>
> - **Subscription renewals do not.** Only the first charge is invoiced; every renewal after it goes
> by without one.
> - **Crypto payments do not.** The CoinGate rail never triggers invoicing.
> - **There is no manual issue-invoice button.** Nothing in the creator interface lets you generate a
> missing invoice yourself.
## What ends up on the invoice
Always exactly **one line item, quantity 1**. Its name is the pricing plan the buyer bought — or the
literal word `Payment` on a one-time sale where the plan can't be resolved — and its gross value is
the amount charged.
| On the invoice | Where it comes from |
| --- | --- |
| Line item name | The pricing plan's name, or `Payment` as a fallback |
| Line item amount | The gross amount actually charged, quantity always 1 |
| VAT rate | The **VAT rate** from your business information; **23%** if you left it empty |
| Buyer name and email | The name and email from checkout |
| Buyer NIP | Never set — see below |
| Sale date, issue date, payment due | All today's date |
| Payment status | Marked **paid** |
| Invoice number | Assigned by your provider; Insy has no numbering of its own |
> **Every invoice goes out to a private person**
>
> Stripe checkout does collect a tax ID from buyers, but Insy never passes it on. No invoice created
> by this integration carries a buyer NIP — inFakt is even told explicitly that the client is a
> private person. A company buyer who typed their NIP at checkout still gets a personal invoice, and
> you'd have to correct it in your provider's panel.
Because the **VAT rate** field is only shown when your business information says *company*, a seller
registered as an individual has no way to change the rate: every invoice goes out at 23%.
## Where the two providers differ
| | Fakturownia | inFakt |
| --- | --- | --- |
| Fields you supply | API key and subdomain | API key |
| Seller details | Taken from your Insy business information | Taken from your inFakt account |
| Currency of the sale | Sent through to the invoice | Not sent — your inFakt account's default is used |
| Amounts sent as | Gross | Net, computed back from the gross amount |
| Buyer name | One field | Split at the first space into first and last name |
| Document link kept by Insy | A PDF link | None |
| Marked paid | In the same request | In the same request, plus a follow-up call a few seconds later |
> **inFakt splits the buyer's name naively**
>
> The checkout name is split on spaces and only the first two parts are used. A one-word name leaves
> the last name empty; a three-part name loses everything after the second word.
## The buyer does not receive it
Insy never sends the invoice to anyone. Fakturownia is given the buyer's email address as a field on
the document and inFakt is given it as the invoice recipient, but Insy never calls either provider's
send-email endpoint — and the document is not shown to the buyer anywhere in Insy either.
If your buyer needs the invoice, send it from your provider's panel.
> **The invoice link in payment history is Stripe's**
>
> Members see an invoice link in their payment history. That is Stripe's own hosted invoice for the
> charge, not the document created in Fakturownia or inFakt.
## KSeF
> **This integration never sends anything to KSeF**
>
> KSeF exists in Insy only on the platform's own side — for the commission invoices Insy issues to
> you — and even there submission is a manual action taken by Insy staff. An invoice created in your
> Fakturownia or inFakt account through this integration is created and left there. If it has to reach
> KSeF, that happens in your provider's panel, on your schedule.
## When it goes wrong
When your provider rejects the request — which is what a wrong, revoked or mistyped key
produces — Insy records the returned status code and response body against the integration and
stops. The card switches to an error state whose badge reads **Payment error**. That label is
shared with other parts of the app and says nothing about the buyer's payment: the sale itself
went through, only the invoice didn't.
The card looks for fields the backend never writes, so it falls back to **Unknown error** every
time, with no status code. The provider's real status code and response body *are* stored — but
no screen displays them. Ask [support@insy.io](mailto:support@insy.io) to read them out for you.
Nothing clears the recorded errors — not reconfiguring the integration, not a later successful
invoice. Once your provider has rejected a single request, the card stays in the error state
permanently. The reliable way to tell whether it works now is to check whether new invoices are
appearing in your provider's account.
If the community or product has no integration, or no API key, or the Stripe account has no
business information saved, generation stops before anything is recorded. There is no error on
the card, no email, and no marker on the sale. Silence is the expected symptom of a
misconfigured setup, so verify against your provider's account rather than against the card.
There is no retry button for creators; only Insy staff can retry a stored invoice record, and a
record only exists if generation got past the checks above. The retry is also lossy: it rebuilds
the document from data that doesn't include the original line, so it goes out as a single line
named `Payment` for the full payment amount, with an empty buyer name. Issuing the invoice by
hand in your provider's panel is usually the cleaner fix.
## Next
The card and crypto rails behind checkout, and which one can trigger an invoice.
What Insy keeps on each sale, and the commission invoice you get for it.