# Connecting to banks, authorities and e-shops · DameDoklad docs

> Orders through a bank's interface, sending filings to the test environment, and e-shops. What works, what is off, and what we have not tried.

Source: https://damedoklad.cz/en/docs/guides/connections/

# Connecting to banks, authorities and e-shops

Orders through a bank's interface, sending filings to the test environment, and e-shops. What works, what is off, and what we have not tried.

You will find connections in **Settings, More, Connections**. An owner and an accountant see them. If you use none, they appear nowhere else.

Everything is off by default. None of these connections has run against a real bank, a live authority portal, a production data box, or a real e-shop. What reliably works today is the order file, the downloaded XML, and statements.

## Banks

| Bank | What is built | State |
| --- | --- | --- |
| Fio banka | Orders (CZK, EUR, foreign), direct debit including SEPA, movements | From the bank’s documentation. Fio has no test environment, tried against our fake |
| Raiffeisenbank | Orders (CZK, EUR, foreign), domestic direct debit, batch status, movements | Unverified, from the published specification. The bank’s test environment needs registration, tried against our fake |
| Komerční banka | Orders (CZK, EUR), batch status, movements. Its batch API takes no foreign payments or direct debits | Unverified, from the published manual and specification |
| Banka CREDITAS | Orders (CZK, EUR, foreign), import status, movements. We send no direct debit through this API | Unverified, from the bank’s console and a third party’s client. We found no test environment |
| Česká spořitelna | Orders (CZK only), batch status, movements. You sign the batch in George | Unverified. The bank’s portal shows nothing without registering: from the public ČOBS standard and a third party’s client, tried against our fake |
| ČSOB | Orders (CZK, EUR), import protocol, movements from GPC statements. You sign the order in CEB. We send no foreign payments or direct debits | Unverified. From third parties’ copies of the bank’s manual and WSDL, tried against our fake |
| MONETA | Movements, and through the PSD2 API domestic payments in crowns, each signed apart in Internet Banka. Orders need PSD2 access from an operator with a licence | Unverified. Orders from the bank’s document and the ČOBS standard, movements from third parties’ clients, tried against our fake |

Sending orders has to be allowed first by the operator, and then by you for a given account.

When it is on, sending goes like this:

1.  In **Bank, Orders**, choose **Send to the bank** on an order.
2.  You see the recipients and amounts, tick that you checked them, and send. It takes an owner or an accountant. Through an API key or an AI agent it works only when the owner has explicitly [turned that on and set limits](/en/docs/authentication/). By default it does not.
3.  The order is loaded into the bank. **The money leaves once you authorise it in internet banking.**

If the bank does not answer, the result is **unknown**: the batch may be there. The app does not send it again by itself. Check internet banking and confirm that the batch is not there.

## Authorities

Sending is available from the filing screens when you have a channel on:

| Channel | What you need | Test environment |
| --- | --- | --- |
| Data box | User name and password of a test box | The public ISDS test, where you can set up a box for free |
| EPO, Financial Administration | A qualified certificate | A check of the file at the Financial Administration’s address, with no filing. The operator has to allow it |
| ČSSZ e-Podání | A qualified certificate and registration with ČSSZ | ČSSZ’s test gateway. The monthly report and registrations do not go this way yet |

**This fulfils no duty.** Sending goes to the test environment only. The operator turns on live filing only after a tax adviser’s review, and until then you keep downloading the XML and filing it yourself. No filing has been sent yet, not even to test.

Only the data box will go live, as it needs no signature. Through EPO and ČSSZ e-Podání the server would sign the filing with your qualified certificate without you, and the app does not do that: those channels are for trials only. You can always file the downloaded XML yourself.

The same file as the download goes out only after you confirm. The status is then read back.

**Careful with received mail.** If you turn on reading the authorities’ answers for a data box, the app downloads the list of received messages. In law that delivers **every message waiting in the box**, and deadlines can start. That is why it is off. Without it the app only sees that your message was delivered, and you find ČSSZ’s answer in the box yourself.

## E-shops

Shoptet, Shopify and WooCommerce. Orders come here and reserve goods. Stock, products and order status go out. You turn on each direction separately.

-   One order is always one document, however many times it is read.
-   What failed is in the **sync log**, item by item, and it is tried again at the next sync.
-   Goods with an unknown code stay on the order as text and reserve nothing. The log says so.
-   On an item, under **More**, you set which shops it is sold in, its categories, attributes and descriptions. Without a shop you will not see this.
-   **Products:** items listed in a shop are created or updated there, with categories, attributes, images and EAN. A product with the same code is taken over, not created twice. What has not changed is not sent. Sets are not sent, and variants go as separate products. In **Settings** you choose whether to send the price with VAT, without VAT, or not at all. A shop in another currency must not get the price, because item prices are in crowns.
-   **GPSR:** the manufacturer, the responsible person in the EU, the product’s EAN and safety information go at the end of the product description, because none of the platforms has a field for them. Article 19 of Regulation (EU) 2023/988 asks this of an offer at a distance; the name and pictures are the product’s own. Write the safety information in Czech.
-   **Order status:** the shop learns that an order is in progress, done or cancelled, each state once. For Shoptet, you map the statuses of your shop in **Settings**, and a state with no mapping is not sent. On Shopify, done means a fulfillment, and cancelled means a cancellation with no refund and no restock, which you decide in Shopify. An order in progress is not sent to Shopify.
-   **Notifications:** once registered and turned on, the shop reports as soon as an order is created or changes, and the order is here within a minute. Reading every 15 minutes carries on. An order cancelled in the shop gives back its reservation here, unless the goods have already left. For Shopify, enter the client secret of your custom app first. Notifications need a public https address for the server.

We tried Shoptet against its official test interface, which answers with sample data, and Shopify and WooCommerce against our own fake. **Nobody has tried it on a real shop yet.** So check the first product in your shop, especially the price: Shoptet’s documentation does not say whether its price includes VAT.

## Connectors for POHODA

Connectors written for POHODA mServer can send XML to `/v1/pohoda/xml`. Use an API key as the password in the `STW-Authorization` header. It can list the address book, stock, orders, invoices and categories, add, update and delete an address and a stock card, add and delete an order, and take an invoice as a draft. A read-only key can only list.

The answers match Stormware’s schemas, but **nobody has tried it with a real connector**. Each record has a numeric ID as in POHODA, which stays the same and is not reused after a delete. Addresses and stock cards can be updated and deleted, and a received order deleted: a draft goes, an issued one is cancelled. POHODA’s schema offers neither update nor delete for invoices, so the server refuses them. A record already in use is not deleted, the same as in the app.