Frequently Asked Questions (FAQ)

Quick answers to common questions about Paysera Open Banking API.

Quick Navigation

Use the tabs below to find answers by category. Click any question to expand the answer.

General Questions

What is Open Banking?

Open Banking is a regulatory framework that allows third-party providers to access bank account information and initiate payments with customer consent. It enables secure sharing of financial data between banks and authorized third parties.

Key Benefits:

Improved financial services innovation
Enhanced customer control over financial data
Increased competition in financial services
Better user experience across financial products

What is PSD2?

PSD2 (Payment Services Directive 2) is the European regulation that mandates Open Banking. It requires banks to:

Provide secure APIs for third-party access
Implement Strong Customer Authentication (SCA)
Allow customers to share their financial data
Enable payment initiation by third parties

Effective Date: September 14, 2019 (full implementation)

What Open Banking services does Paysera provide?

Paysera provides two main Open Banking services:

📊 Account Information Service (AIS)

Access to account information
Balance inquiries
Transaction history

💳 Payment Initiation Service (PIS)

Single payments, products domestic and foreign
Payment status tracking

📖 Getting Started Guide →

Do I need a license to use Open Banking APIs?

Yes, you need to be a registered Third Party Provider (TPP) with appropriate licenses:

AISP License - For account information services

View account details
Access transaction history
Read balance information

PISP License - For payment initiation services

Initiate payments on behalf of users
Check payment status

How to Register:

Obtain license from your national competent authority
Register with Paysera as a TPP
Complete technical onboarding
Start using the APIs

Authentication & Security

How do I authenticate API requests?

Paysera Open Banking API uses OAuth 2.0 for authentication:

# 1. Get access token
POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET

# 2. Use token in API requests
GET /v1/accounts
Authorization: Bearer YOUR_ACCESS_TOKEN

Token Validity:

Access tokens: 1 hour
Refresh tokens: Not applicable for client credentials flow

📖 Authentication Guide →

What security measures are implemented?

🔒 Security Features

Strong Customer Authentication (SCA)

Two-factor authentication for sensitive operations
Biometric or PIN verification
Dynamic linking for payment authorization

Technical Security

OAuth 2.0 authorization
TLS 1.2+ encryption
Mutual TLS (mTLS) for API access
IP whitelisting available

Data Protection

GDPR compliant
Data minimization
Explicit user consent
Audit logging

📖 Security Documentation →

How long are consents valid?

Account Information (AIS)

Default: 90 days
Maximum: 180 days
Can be renewed before expiry
User can revoke anytime

Payment Initiation (PIS)

Single immediate payments: One-time use
Future dated payments: Until execution date
Recurring payments: As specified by user

Best Practices:

Track consent expiry dates
Notify users before expiry
Implement automatic renewal flows
Respect user revocation immediately

Account Information Service (AIS)

What account information can I access?

With proper consent, you can access:

📋 Account Details

Account name and IBAN
Account type and currency
Account status

💰 Balance Information

Current balance
Available balance
Credit limit (if applicable)

📜 Transaction History

Transaction amount and currency
Transaction date and description
Merchant information
Transaction status

📖 API Endpoints →

How do I get user consent for account access?

1. Create Consent Request

POST /v1/consents
{
  "access": {
    "accounts": ["IBAN1", "IBAN2"],
    "balances": ["IBAN1", "IBAN2"],
    "transactions": ["IBAN1", "IBAN2"]
  },
  "recurringIndicator": true,
  "validUntil": "2024-12-31"
}

2. Redirect User for Authorization

https://bank.paysera.com/authorize?consent_id=CONSENT_ID

3. User Approves in Paysera

User logs in
Reviews requested permissions
Confirms with SCA

4. Receive Consent Status

GET /v1/consents/{consentId}/status

📖 Consent Examples →

What are the rate limits for AIS?

🚦 Rate Limiting

Without User Presence:

4 requests per day per consent
Applied per account
Resets at midnight CET

With User Presence (PSU Active):

Unlimited requests
User must be actively authenticated
Session typically lasts 5 minutes

Best Practices:

Cache account information appropriately
Implement exponential backoff
Request only needed data

Error Response:

{
  "tppMessages": [{
    "category": "ERROR",
    "code": "ACCESS_EXCEEDED",
    "text": "Daily access limit exceeded"
  }]
}

Payment Initiation Service (PIS)

What types of payments can I initiate?

💸 Supported Payment Types

The Georgia v0.8 profile has two payment products, domestic and foreign:

POST /v1/payments/domestic
POST /v1/payments/foreign

Both take the same request body and are validated the same way:

instructedAmount in any ISO 4217 currency
creditorAccount identified by IBAN (the only supported account identifier)
creditorName (required, up to 70 characters)

Optional:

debtorAccount - if omitted, the PSU selects it during authorisation
remittanceInformationUnstructured
endToEndIdentification
creditorAgent (BIC)
creditorAgentName
creditorAddress

Payments are executed as standard (non-instant) transfers, without automatic currency conversion.

Bulk, periodic and instant payments are not supported. SEPA and Target2 products belong to the Berlin Group v1.3 profile and are not available on the Georgia base URL.

📖 Payment Examples →

What information is required to initiate a payment?

📝 Required Payment Data

POST /v1/payments/domestic
{
  "instructedAmount": {
    "currency": "GEL",
    "amount": "100.00"
  },
  "creditorAccount": {
    "iban": "GE00BG0000000000000001"
  },
  "creditorName": "Beneficiary Name",
  "remittanceInformationUnstructured": "Payment reference"
}

Mandatory Fields:

Creditor IBAN (creditorAccount.iban)
Creditor name (creditorName, up to 70 characters)
Amount and currency (instructedAmount)

Optional Fields:

Debtor account (debtorAccount) - if omitted, the PSU selects it during authorisation
Payment reference (remittanceInformationUnstructured)
endToEndIdentification
creditorAgent (BIC)
creditorAgentName
creditorAddress

Can I check payment status?

📊 Payment Status Tracking

Check Payment Status:

GET /v1/payments/domestic/{paymentId}/status

Possible Status Values:

RCVD - Received
PDNG - Pending
ACTC - AcceptedTechnicalValidation
ACCP - AcceptedCustomerProfile
ACSC - AcceptedSettlementCompleted
RJCT - Rejected
CANC - Cancelled

Status Transitions:

RCVD → PDNG → ACTC → ACCP → ACSC
         ↓      ↓      ↓
        RJCT   RJCT   RJCT

Cancellation: not supported. A DELETE request on a payment is rejected with 405 SERVICE_INVALID.

Technical Implementation

What API endpoints are available?

📦 API Versioning

Open Banking API maintains multiple versions:

v1.3 Berlin Group Standard

URL: https://open-banking-api.paysera.com/xs2a/berlin/1.3/v1/
Documentation: Berlin Group v1.3
Coverage: EU/EEA countries

v0.8 Georgia Version

URL: https://open-banking-api.paysera.com/xs2a/georgia/0.8/v1/
Documentation: Georgia v0.8
Coverage: Georgia specific implementation

📍 Main API Endpoints

Consent Management

POST /v1/consents - Create consent
GET /v1/consents/{id} - Get consent details
DELETE /v1/consents/{id} - Delete consent
GET /v1/consents/{id}/status - Check status

Account Information

GET /v1/accounts - List accounts
GET /v1/accounts/{id} - Account details
GET /v1/accounts/{id}/balances - Balances
GET /v1/accounts/{id}/transactions - Transactions

Payment Initiation

POST /v1/payments/{type} - Initiate payment
GET /v1/payments/{type}/{id} - Payment details
GET /v1/payments/{type}/{id}/status - Status

📖 Full API Reference →

What data formats are supported?

📐 Standard Data Formats

Request/Response Format

Content-Type: application/json
Character encoding: UTF-8

Date & Time

Format: ISO 8601
Example: 2024-12-31T23:59:59Z
Timezone: UTC

Currency

Format: ISO 4217
Example: EUR, USD, GBP

Country Codes

Format: ISO 3166-1 alpha-2
Example: LT, DE, FR

IBAN

Format: ISO 13616
Example: GE00BG0000000000000001

Amount

Format: String with 2 decimal places
Example: "100.00"

How should I handle errors?

⚠️ Error Handling

Standard Error Format:

{
  "tppMessages": [
    {
      "category": "ERROR",
      "code": "FORMAT_ERROR",
      "path": "instructedAmount.amount",
      "text": "Invalid amount format"
    }
  ],
  "_links": {
    "self": {
      "href": "/v1/payments/123"
    }
  }
}

Common HTTP Status Codes:

400 - Bad Request (validation error)
401 - Unauthorized (invalid token)
403 - Forbidden (insufficient permissions)
404 - Not Found
409 - Conflict (duplicate request)
429 - Too Many Requests
500 - Internal Server Error

Error Categories:

ERROR - Request failed
WARNING - Request processed with issues

Best Practices:

Log all errors with correlation IDs
Implement retry logic with backoff
Handle specific error codes appropriately
Provide user-friendly error messages

Are there sandbox/test environments?

🧪 Test Environment

Sandbox Environment:

⚠️ Status: Work in Progress (both Berlin Group v1.3 and Georgia v0.8)

Sandbox URLs will be announced when available:

# For Berlin Group v1.3 (⚠️ Coming Soon)
# https://open-banking-sandbox.paysera.com/xs2a/berlin/1.3/

# For Georgia v0.8 (⚠️ Coming Soon)
# https://open-banking-sandbox.paysera.com/xs2a/georgia/0.8/

Planned Features:

Test credentials available after TPP registration
Separate from production credentials
Full API functionality
No real money movement
Unlimited API calls
Error simulation
SCA bypass for testing

📖 Updates will be announced when sandbox becomes available.

Common Troubleshooting Steps

See the sections below for the most common errors and their solutions.

Is the URL 'open-banking.paysera.com' or 'open-banking-api.paysera.com'?

Both URLs are correct, but they serve different purposes:

🔗 URL Usage

Backend API requests:

https://open-banking-api.paysera.com/xs2a/georgia/0.8/v1/

Use this for all API calls (consents, accounts, payments). The host alone is not the API base: every XS2A path lives under the profile prefix.

Frontend interface:

https://open-banking.paysera.com

Redirect users here for authorization and consent approval

Example Flow:

Create consent via API: POST https://open-banking-api.paysera.com/xs2a/georgia/0.8/v1/consents
Redirect user to: https://open-banking.paysera.com/authorize?consent_id=XXX
After approval, use API: GET https://open-banking-api.paysera.com/xs2a/georgia/0.8/v1/accounts

Error: invalid_client

❌ Error: invalid_client

Common Causes & Solutions:

✅ Ensure client_id is included and not blank

{
  "client_id": "PSDLT-BANK-123456"  // ✅ Correct
}

✅ Use certificate identifier, not numerical ID

Correct: "PSDxx-xx-xxxxx" (certificate identifier)
Wrong: "123" (numerical value)

✅ Verify certificate is properly registered

Certificate must be uploaded to Paysera
Certificate must be valid (not expired)
Certificate must match the client_id

Still having issues? Contact tech_support@paysera.com with:

Your API request (without secrets)
The error response
Your certificate identifier

Error: Provided data is incorrect. Please try again.

❌ Error: Provided data is incorrect

This is a validation error that can occur for various reasons:

Common Causes:

Invalid IBAN format
Incorrect date format (use ISO 8601)
Missing required fields
Invalid currency code
Incorrect amount format

Troubleshooting Steps:

Verify all required fields are present
Check data formats match API specifications
Ensure IBANs are valid and exist
Validate JSON structure

Need Help? Please contact tech_support@paysera.com with:

Complete API request
Full error response
Request timestamp

Error: The requested scope is invalid, unknown, or malformed

❌ Error: Invalid Scope

Common Causes:

The scope is not AIS:<consentId> or PIS:<paymentId>. Permission-style names such as accounts or payments are rejected.
The ID after the prefix is not the one Paysera returned (a typo, or not a UUID)
No consent or payment with that ID exists

Valid Scopes:

AIS:<consentId> - authorise the consent returned by the consent request
PIS:<paymentId> - authorise the payment returned by the payment initiation request

Resolution: Compare the ID in the scope with the consentId or paymentId in the response that created it. If they match, contact tech_support@paysera.com with:

Your API request
The error response

Can the default language of the Paysera authorization page be changed?

🌐 Language Settings

Setting Language via URL Parameter:

https://open-banking.paysera.com/authorize?consent_id=XXX&lng=en

Supported Languages:

en - English
lt - Lithuanian
lv - Latvian
ee - Estonian
ru - Russian
pl - Polish
de - German

Important Notes:

Language cannot be set in the authorization request API call itself
The page remembers the user's last language choice
Users can manually change language on the authorization page

Support & Resources

Where can I find the full API documentation?

📚 Documentation Resources

API Documentation

Standards & Specifications

Code Examples

Additional Resources

How do I report issues or get support?

📞 Contact Support / Escalation Channels

Technical Support

Email: tech_support@paysera.com
Response time: 1-2 business days

Developer Support

Email: tech_support@paysera.com
For integration questions and API guidance

When Reporting Issues, Include:

API endpoint and method
Request headers (without secrets)
Request/response bodies
Error messages
Correlation/Request IDs
Timestamp of the issue

Bug Reports

Detailed description
Steps to reproduce
Expected vs actual behavior
Environment (sandbox/production)

Feature Requests

Business use case
Technical requirements
Priority level

Emergency Support

Production issues: Contact account manager
Critical bugs: Mark email as "URGENT"

What about GDPR compliance?

Data Processing Principles

Lawfulness and transparency
Purpose limitation
Data minimization
Accuracy
Storage limitation
Security

User Rights

Right to access
Right to rectification
Right to erasure ("right to be forgotten")
Right to data portability
Right to object

Your Responsibilities as TPP:

Obtain explicit consent
Process data only as authorized
Implement appropriate security measures
Maintain processing records
Report data breaches within 72 hours
Appoint DPO if required

Paysera's Commitment:

GDPR compliant infrastructure
Data Processing Agreements available
Regular security audits
Encrypted data transmission and storage

📖 Privacy Policy

Best practices for implementation?

✅ Implementation Best Practices

Security

Store credentials securely (use vault)
Implement certificate pinning
Use mutual TLS where available
Regular security audits

Performance

Cache account information appropriately
Implement connection pooling
Use pagination for large datasets
Compress API requests/responses

Reliability

Implement retry logic with exponential backoff
Handle timeout scenarios
Use circuit breakers
Monitor API health

User Experience

Clear consent explanations
Transparent data usage
Easy consent revocation
Helpful error messages

Compliance

Log all API interactions
Implement audit trails
Regular compliance reviews
Stay updated with regulations

Development

Use sandbox extensively
Implement comprehensive testing
Version your API integration
Document your implementation

Still Have Questions?

If you couldn't find the answer you're looking for:

📧 Email Support

tech_support@paysera.com

Technical questions and integration support

📖 Documentation

View Full Docs

Detailed guides and API reference

💬 Community

Developer Forum

Discuss with other developers

Last updated: November 2024

General Questions​

📊 Account Information Service (AIS)​

💳 Payment Initiation Service (PIS)​

Authentication & Security​

🔒 Security Features​

⏱️ Consent Validity Periods​

Account Information Service (AIS)​

📋 Account Details​

💰 Balance Information​

📜 Transaction History​

📝 Consent Flow​

🚦 Rate Limiting​

Payment Initiation Service (PIS)​

💸 Supported Payment Types​

📝 Required Payment Data​

📊 Payment Status Tracking​

Technical Implementation​

📦 API Versioning​

📍 Main API Endpoints​

📐 Standard Data Formats​

⚠️ Error Handling​

🧪 Test Environment​

Common Troubleshooting Steps​

🔗 URL Usage​

❌ Error: invalid_client​

❌ Error: Provided data is incorrect​

❌ Error: Invalid Scope​

🌐 Language Settings​

Support & Resources​

📚 Documentation Resources​

📞 Contact Support / Escalation Channels​

🔒 GDPR Compliance​

✅ Implementation Best Practices​

Still Have Questions?​

📧 Email Support​

📖 Documentation​

💬 Community​

General Questions

📊 Account Information Service (AIS)

💳 Payment Initiation Service (PIS)

Authentication & Security

🔒 Security Features

⏱️ Consent Validity Periods

Account Information Service (AIS)

📋 Account Details

💰 Balance Information

📜 Transaction History

📝 Consent Flow

🚦 Rate Limiting

Payment Initiation Service (PIS)

💸 Supported Payment Types

📝 Required Payment Data

📊 Payment Status Tracking

Technical Implementation

📦 API Versioning

📍 Main API Endpoints

📐 Standard Data Formats

⚠️ Error Handling

🧪 Test Environment

Common Troubleshooting Steps

🔗 URL Usage

❌ Error: invalid_client

❌ Error: Provided data is incorrect

❌ Error: Invalid Scope

🌐 Language Settings

Support & Resources

📚 Documentation Resources

📞 Contact Support / Escalation Channels

🔒 GDPR Compliance

✅ Implementation Best Practices

Still Have Questions?

📧 Email Support

📖 Documentation

💬 Community