Executing Orders
Upload payment files and download statements using EBICS business transactions.
Once your EBICS user is initialized, you can execute business transactions. This guide covers uploading payment files and downloading statements.
Order Types
EBICS distinguishes between two main order directions:
| Direction | Description | Examples |
|---|---|---|
| Upload | Send data to bank | Payments, Direct Debits |
| Download | Receive data from bank | Statements, Reports |
Business Transaction Format (BTF)
EBICS 3.0 (H005/H006) uses BTF parameters to identify the type of business transaction. BTF replaces the legacy 3-letter order type codes with a flexible service-based approach consisting of:
- Service - The business service type (e.g., SCT for SEPA Credit Transfer)
- Message - The ISO 20022 message type (e.g., pain.001)
- Scope - Geographic or regulatory scope (e.g., DE for Germany)
- Option - Optional service modifier (e.g., URG for urgent)
Common BTF Services
| Service | Description | Message Type |
|---|---|---|
SCT |
SEPA Credit Transfer | pain.001 |
SDD |
SEPA Direct Debit | pain.008 |
SCI |
SEPA Credit Instant | pain.001 |
Statement |
Account Statement | camt.053 |
Intraday |
Intraday Statement | camt.052 |
Notification |
Debit/Credit Notification | camt.054 |
Upload Orders
Upload orders (BTU in H005/H006, FUL in legacy versions) send data from your system to the bank, such as payment instructions or direct debit mandates.
Upload Transaction Flow
┌──────────────────────────────────────────────────────────────┐
│ UPLOAD TRANSACTION │
├──────────────────────────────────────────────────────────────┤
│ │
│ Phase 1: Initialization │
│ ──────────────────────── │
│ • Validate order data │
│ • Sign with Electronic Signature (ES) │
│ • Encrypt order data │
│ • Send initialization request │
│ • Receive TransactionID │
│ │
│ Phase 2: Data Transfer │
│ ────────────────────── │
│ • Split data into segments (if large) │
│ • Send each segment │
│ • Receive confirmation │
│ │
│ Result: Order submitted to bank │
│ │
└──────────────────────────────────────────────────────────────┘
Signature Classes
Your signature class determines whether the order executes immediately or requires additional signatures:
| Class | Name | Behavior |
|---|---|---|
| E | Single Signature | Order executes immediately |
| A | First Signature | Requires co-signature (A or B) |
| B | Second Signature | Requires first signature (A) |
| T | Transport Only | Cannot authorize, upload only |
Download Orders
Download orders (BTD in H005/H006, FDL in legacy versions) retrieve data from the bank, such as account statements, payment status reports, or acknowledgements.
Download Transaction Flow
┌──────────────────────────────────────────────────────────────┐
│ DOWNLOAD TRANSACTION │
├──────────────────────────────────────────────────────────────┤
│ │
│ Phase 1: Initialization │
│ ──────────────────────── │
│ • Send download request with parameters │
│ • Receive TransactionID and segment count │
│ • Receive first data segment │
│ │
│ Phase 2: Data Transfer │
│ ────────────────────── │
│ • Request remaining segments │
│ • Decrypt received data │
│ • Decompress if needed │
│ │
│ Phase 3: Receipt │
│ ─────────────────── │
│ • Send receipt acknowledgment │
│ • Bank marks data as delivered │
│ │
│ Result: Data received and acknowledged │
│ │
└──────────────────────────────────────────────────────────────┘
Order Status
Orders progress through several states:
| Status | Description |
|---|---|
PENDING |
Order created, not yet submitted |
PENDING_SIGNATURE |
Awaiting additional signatures (VEU) |
SUBMITTED |
Sent to bank, awaiting processing |
COMPLETED |
Successfully processed |
FAILED |
Processing failed |
CANCELLED |
Cancelled by user or bank |
Error Handling
Common Return Codes
| Code | Name | Action |
|---|---|---|
000000 |
EBICS_OK | Success |
011000 |
EBICS_DOWNLOAD_POSTPROCESS_DONE | Success, no more data |
090005 |
EBICS_NO_DOWNLOAD_DATA_AVAILABLE | No data for date range |
091002 |
EBICS_INVALID_USER_STATE | User not initialized |
091010 |
EBICS_INVALID_ORDER_PARAMS | Check BTF parameters |
Transaction Recovery
If a transaction fails mid-transfer, EBICS supports recovery. The client automatically attempts to resume failed transactions from the last successful segment, up to a configurable maximum number of retry attempts.
Recovery is only available if the bank supports it (indicated in the HPD response). The client tracks recovery attempts and will mark a transaction as permanently failed if recovery is not possible.
Best Practices
- Always check return codes - Don't assume success
- Store transaction IDs - Needed for recovery and tracking
- Use date ranges wisely - Large ranges may timeout
- Handle duplicates - Banks may reject duplicate uploads
- Monitor VEU status - Orders may need co-signatures
Next Steps
- VEU Workflows - Multi-signer authorization
- Return Codes - Complete error reference
- BTF Reference - All BTF parameters