France

Fiscalisation for France

Helps POS software vendors comply with fiscalization laws and VAT reporting for B2C, B2B and B2G sales across Europe via a single, lightweight app.

Overview

Viva Fiscal API is designed to help businesses comply with fiscalization laws, especially in countries with strict regulations on tax reporting and cash register security. It acts as an intermediary between a company’s point-of-sale (POS) system and government tax authorities, ensuring that all transactions are accurately recorded, securely signed, and transmitted in compliance with legal requirements.

Benefits

POS Integrations

Viva offers Auto Fiscalization functionality within its POS integrations, providing an electronic fiscalization service that allows businesses to record, process, and store transactions digitally. This ensures transparency, accuracy, and compliance without complex procedures.

Fiscalization is available through:

Merchants and ISV partners do not need to allocate resources for fiscalization integration, as all transactions are automatically fiscalized during payments.

Partners working with other PSPs can also use Viva’s standalone Fiscal API to transmit data to regulators and receive valid receipt information.

The fiscalisation feature is currently available exclusively on our SoftPOS for Android. Please use this link to download the demo version of the Viva Terminal app with fiscalisation enabled and try it out in demo environment.

How to Fiscalize POS Payments

Ensuring that a payment is tax-compliant is quite straightforward. Your integration remains the same, with just one additional object added to your sale requests. This object(fiscalisationData) contains essential data, including the items sold, the payment amount for each item, and the corresponding VAT details. You can find the object structure and its parameters here.

The fiscalisationData is same across all types of POS integrations. By understanding what to include in your requests, you can seamlessly integrate fiscalisation into Viva’s any POS integration. Viva Fiscalisation handles the compliance process by signing the transaction with the relevant authorities. It then returns the receipt details, including the required signature for tax authorities. This information must be printed on the receipt and provided to the customer.

Fiscalisation Data Object

The table below presents the parameter details for the fiscalizationData. The fiscalization data contains the core details required for tax compliance.

Fiscalisation Data Parameters

The fiscalisationData object contains the below parameters.

Value Description Example Mandatory field
cbChargeItems An array of objects, each representing an individual item sold, including details such as description, quantity, price, and VAT. For more details about cbChargeItems parameter, please click here. [{“amount”:40,“description”:“description1”,“position”:1,“quantity”:100,“unit”:“pcs”,“unitPrice”:40,“vatAmount”:1,“vatRate”:2400,“currencyCode”:“978”,“moment”:“2025-04-24T22:09:32.521Z”,“ftChargeItemCaseData”:{“taxable”:true},“ftChargeItemCase”:5139205309155246083}]
cbPayItems An array of objects specifying the payment details, including payment method, amount, and references. For more details about cbPayItems parameter, please click here. [{“amount”:40,“description”:“Card”,“position”:1,“currencyCode”:“978”,“moment”:“2025-04-24T22:09:32.521Z”,“ftPayItemCase”:5139205309155246085}]
cbUser The data object representing the identification of the user who creates the receipt. For more details about cbUser parameter, please click here. {“merchantName”:“Merchant”,“cashier”:{“name”:“JohnDoe”,“id”:10}}
cbCustomer The data object representing the identification of the business customer for whom the receipt is created. For more details about cbCustomer parameter, please click here. {“customerVATId”:“EL999999999”,“customerCountry”:“GRC”,“customerName”:“ProfessionalServicesLTD”,“customerStreet”:“AmarousiouChalandriou18-20”,“customerZip”:“15125”,“customerCity”:“Athens”}
cbReceiptMoment The time of receipt creation. Must be provided in UTC 2025-04-24T22:09:32.521Z
cbReceiptReference The reference number sent by the cash register. Ideally, this should be a unique receipt identifier provided by the cash register, enabling the return value to be stored in the cash register’s dataset. Unique reference of the receipt
ftReceiptCase This field defines the receipt type, determines if the receipt has to be secured accordingly to the national law, and establishes the way to calculate the correct values for each national counter. For more details about ftReceiptCase parameter, please click here. 5139205309155246081
currencyCode The numeric code of the transaction’s currency as defined in ISO 4217 978

Example

The order includes one product, Coffee Latte, with grand total amount of 4 euro (1 item Coffee Latte x 4 euro ). The fiscalisationData sample is as below:

{
    "cbChargeItems": [
        {
            "amount": 400,
            "description": "Coffee Latte",
            "position": 1,
            "quantity": 100,
            "unit": "pcs",
            "unitPrice": 400,
            "vatAmount": 96,
            "vatRate": 2400,
            "currencyCode": "978",
            "moment": "{{$isoTimestamp}}",
            "ftChargeItemCaseData": {
                "taxable": true
            },
            "ftChargeItemCase": 5139205309155246083
        }
    ],
    "cbPayItems": [
        {
            "amount": 400,
            "description": "Card",
            "position": 1,
            "currencyCode": "978",
            "moment": "{{$isoTimestamp}}",
            "ftPayItemCase": 5139205309155246085
        }
    ],
    "cbUser": {
        "merchantName": "Merchant",
        "cashier": {
            "name": "John Doe",
            "id": 10
        }
    },
     "cbCustomer":
     {
         "customerVATId": "EL999999",
         "customerCountry": "GRC",
         "customerName": "Professional Services LTD",
         "customerStreet": "Street 18-20",
         "customerZip": "99999",
         "customerCity": "Athens"
     },    
    "cbReceiptMoment": "{{$isoTimestamp}}",
    "cbReceiptReference": "Unique reference of the receipt",
    "ftReceiptCase": 5139205309155246081,
    "currencyCode": "978"
}

cbChargeItems Array

Inside the fiscalisationData object, the cbChargeItems array holds the product/item details that the invoice includes.

Field name Description Sample data Mandatory field Visualized on receipt
amount Gross total price of service(s). The gross individual price, net total price, and net individual price, have to be calculated using the amount and VAT rate/amount 400 yes
quantity Amount or volume (number) of service(s) or items of the entry 1 yes
description Name, description of customary indication, or type of the service or item Kaffee yes
vatRate Represents the value-added tax (VAT) rate, where the last two digits represent the decimal component. For example, a value of 2400 corresponds to a VAT rate of 24.00%, and 850 corresponds to 8.50%. This fixed-point representation avoids floating-point precision issues. 2000 yes
ftChargeItemCase Type of service or item according to the reference table in the appendix. For more details about ftChargeItemCase parameter, please click here. 5139205309155246083 no
Moment Time of service (UTC format) 2023-08-01T07:47:53.68Z no
vatAmount Can be used to calculate the net amount to avoid rounding errors 80 yes
ftChargeItemCaseData Additional data about the service, currently accepted only in JSON format {"taxable": true} currently not*
accountNumber Account number for transfer into bookkeeping 1234 no
costCenter Indicator for transfer into cost accounting (type, center, and payer) 1 no
productGroup This value allows the customer the logical grouping of products Kaffee no
productNumber Value used to identify the product 123 no
productBarcode Product’s barcode 16514646137 currently not*
unit Unit of measurement pcs no
unitQuantity Quantity of the service(s) of receipt entry, displayed in indicated units - no
unitPrice Gross price per indicated unit 400 no
currencyCode Used as currency code for money numbers in ISO 4217 978
ftChargeItemCase Parameter for France

The ftChargeItemCase: in the ‘cbChargeItems’ object defines the type of service or item in the line item block and thus how Viva processes the individual receipts with regards to receipt generation. The data type is Int64 and contains a country specific code which is a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7.

Example for ftChargeItemCase : 5067112530745229312

Calculation: After you identify the type of service value (Eg: The value 4652000000000000 in hexadecimal format in the below table) you should convert it to its decimal equivalent(Eg: 5067112530745229312) and then include it in the request data.

A helpful online tool for your converting tests is [this](https://www.rapidtables.com/convert/number/hex-to-decimal.html).

Value Description
4652000000000000 Unknown type of service for FR
With the help of the VAT-rates table saved within Viva fiscalisation, an allocation to standard /reduced-1 /reduced-2 / super-reduced/zero is attempted.
4652000000000001 Undefined type of service for FR reduced-1
(as of 1.1.2017, this is calculated with 5,5%).
4652000000000002 Undefined type of service for FR reduced-2
(as of 1.1.2016, this is calculated with 10%,
Loi n° 2015-1786 du 29 décembre 2015, art. 79).
4652000000000003 Undefined type of service for FR normal
(as of 1.1.2014, this is 20%,
Loi n° 2012-1510 du 29 décembre 2012, art. 68-III-B).
4652000000000004 Undefined type of service for FR special (super-reduced)
Includes all rates that are not contained in the previous ones (as of 1.1.2017, this can be, for example, 2,1%).
4652000000000005 Undefined type of service for FR zero
Includes data indicated with 0% sales tax and data where the sales tax is unknown, for example, about an outgoing invoice. Also, in cases where the sales tax should not be apparent, for example, in differential taxation, the data can be issued with this code.
4652000000000006 Reverse charge
Reversal of tax liability.
4652000000000007 Not own sales
In the data, a VAT-rate can be indicated.
4652000000000008 Delivery reduced-1
For processing, see ( 4652000000000001)
4652000000000009 Delivery reduced-2
For processing, see ( 4652000000000002)
465200000000000A Delivery normal
For processing, see ( 4652000000000003)
465200000000000B Delivery special
For processing, see ( 4652000000000004)
465200000000000C Delivery zero
For processing, see ( 4652000000000005)
465200000000000D Other services reduced-1
For processing, see ( 4652000000000001)
465200000000000E Other services reduced-2
For processing, see ( 4652000000000002)
465200000000000F Other services normal
For processing, see ( 4652000000000003)
4652000000000010 Other services special
For processing, see ( 4652000000000004)
4652000000000011 Other services zero
For processing, see ( 4652000000000005)
4652000000000012 Catalogue services reduced-1
For processing, see ( 4652000000000001)
4652000000000013 Catalogue services reduced-2
For processing, see ( 4652000000000002)
4652000000000014 Catalogue services normal
For processing, see ( 4652000000000003)
4652000000000015 Catalogue services special
For processing, see ( 4652000000000004)
4652000000000016 Catalogue services zero
For processing, see ( 4652000000000005)
4652000000000017 Own consumption reduced-1
For processing, see ( 4652000000000001)
4652000000000018 Own consumption reduced-2
For processing, see ( 4652000000000002)
4652000000000019 Own consumption normal
For processing, see ( 4652000000000003)
465200000000001A Own consumption special
For processing, see ( 4652000000000004)
465200000000001B Own consumption zero
For processing, see ( 4652000000000005)
465200000000001C Prepayment reduced-1
For processing, see ( 4652000000000001)
465200000000001D Prepayment reduced-2
For processing, see ( 4652000000000002)
465200000000001E Prepayment normal
For processing, see ( 4652000000000003)
465200000000001F Prepayment special
For processing, see ( 4652000000000004)
4652000000000020 Prepayment zero
For processing, see ( 4652000000000005)
4652000000000021 Account of a third party/ third party name/ collection
For processing, see ( 4652000000000007)
4652000000000022 Obligation
Example

The order includes one product, Coffee Latte, with grand total amount of 4 euro (1 item Coffee Latte x 4 euro ). The cbChargeItems sample is as below:

"cbChargeItems":
[
    {
        "amount": 400,
        "description": "Coffee Latte",
        "position": 1,
        "quantity": 100,
        "unit": "pcs",
        "unitPrice": 400,
        "vatAmount": 96,
        "vatRate": 2400,
        "currencyCode": "978",
        "moment": "2025-04-24T13:13:28.545Z",
        "ftChargeItemCaseData":
        {
            "taxable": true
        },
        "ftChargeItemCase": 5139205309155246083
    }
]

cbPayItems Array

cbPayItems array holds the payment details that the invoice includes.

Field Name Description Sample Data Mandatory Field
amount Total amount of payment 400
quantity Number of payments. This value will be set to 1 in most of the cases. It can be greater than 1 e.g. when paying with multiple vouchers of the same value. 1
description Name or description of payment Card
ftPayItemCase Type of payment according to the reference table in the appendix. It is used in order to determine the processing logic. For more details about ftPayItemCase parameter, please click here. 5139205309155246085
moment Time of payment. Must be provided in UTC, e.g. 2020-06-29T17:45:40.505Z. 2025-04-24T13:13:28.545Z
position Line number or position number on the receipt. Used to preserve the order of lines on the receipt. 1
currencyCode Used as currency code for money numbers in ISO 4217 978
accountNumber Account number for transfer into bookkeeping String
costCenter Indicator for transfer into cost accounting (type, center and payer) String
moneyGroup This value allows the logical grouping of payment types. String
moneyNumber This value identifies the payment type. String
ftPayItemCase Parameter for France

The ftPayItemCase in the ‘cbPayItems’ object indicates the type of payment within the pay items block and defines how the Viva Fiscalisation processes the individual payment in terms of the receipt. The data type is Int64 and contains a country specific code which is a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7.

The format of the `ftPayItemCase` parameter on payments item level, should be as below.

Example for payments ftPayItemCase : 5067112530745229312

Calculation: After you identify the type of payment value (Eg: The value 4652000000000000 in hexadecimal format in the below table) you should convert it to its decimal equivalent(Eg: 5067112530745229312) and then include it in the request data.

A helpful online tool for your converting tests is [this](https://www.rapidtables.com/convert/number/hex-to-decimal.html).

Value Description
4652000000000000 Default value
Unknown payment type: Automatic processing through the Viva fiscalisation settings is attempted.
4652000000000000 Unknown payment type for FR
This is handled like a cash payment in national currency.
4652000000000001 Cash payment in national currency
cash
4652000000000002 Cash payment in foreign currency
cash
4652000000000003 Crossed cheque
cash
4652000000000004 Debit card payment
noncash
4652000000000005 Credit card payment
cash
4652000000000006 Voucher payment (coupon) - voucher by money value
cash
4652000000000007 Online payment
noncash
4652000000000008 Customer card payment
noncash
4652000000000009 Other debit card
noncash
465200000000000A Other credit card
cash
465200000000000B Account receivable
Delivery note/ settlement in foreign currency
internal
465200000000000C SEPA transfer
noncash
465200000000000D Other transfer
noncash
465200000000000E Cash book expense
internal
465200000000000F Cash book contribution
internal
4652000000000010 Levy
internal
4652000000000011 Internal/ material consumption
Can be used for bill
internal
4652000000000012 Change
tip
cash
Example

The order includes one product, Coffee Latte, with grand total amount of 4 euro (1 item Coffee Latte x 4 euro ). The cbPayItems sample is as below:

"cbPayItems": [
    {
        "amount": 400,
        "description": "Card",
        "position": 1,
        "currencyCode": "978",
        "moment": "2025-04-24T13:13:28.545Z",
        "ftPayItemCase": 5139205309155246085
    }
]

cbUser Object

cbUser object indicates the user, who creates the receipt. Although all string values are supported, we suggest using data structures serialized into JSON format.

Example

The order includes two products, one Coffee Latte and two Coffee Cappuccino, with grand total amount of 20 euro (1 item Coffee Latte x 10 euro + 2 Coffees Cappuccino x 5 euro). The payments array, will be the below:

"cbUser": {
    "merchantName": "Merchant",
    "cashier": {
        "name": "John Doe",
        "id": 10
    }
}

cbCustomer Object

cbCustomer object is used when the receipt is for a business customer.

Field Name Description Sample Data Mandatory Field
customerName Name of beneficiary customer. John Dohn's Company
customerStreet Street and house number of the beneficiary customer. York Road
customerZip Zip of the beneficiary customer. 1234
customerCity City of the beneficiary customer. Athens
customerCountry Country of the beneficiary customer. [ISO 3166 ALPHA-3 country code](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3). GRC
customerVATId VAT-ID of the beneficiary customer. EL999999
Example
     "cbCustomer":
     {
         "customerVATId": "EL999999",
         "customerCountry": "GRC",
         "customerName": "Professional Services LTD",
         "customerStreet": "Street 18-20",
         "customerZip": "99999",
         "customerCity": "Athens"
     }

Understanding ftReceiptCase for France

The ftReceiptCase in the ‘main body’ indicates the receipt type and defines how it should be processed by the Viva Fiscalisation. The data type is Int64 and contains the country specific code, which is a value following the ISO-3166-1-ALPHA-2 standard converted from ASCII into hex and used as byte 8 and 7. For definitions regarding national laws, please refer to each country seperately.

For France (FR), the country code is 4652. Thus, the value of an unknown ftReceiptCase in France is 4652000000000000.

Example for POS receipt : 4652000000000000

The value 4652000000000000 is in hexadecimal format and needs to be converted to its decimal equivalent, which is 5067112530745229312. Therefore, the value to be included in the request body should be 5067112530745229312.

A helpful online tool for your converting tests is [this](https://www.rapidtables.com/convert/number/hex-to-decimal.html).

Value Description
4652000000000000 Unknown receipt for FR
Processed like a ticket
4652000000000001 Ticket
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: T
Details: GT counters are raised
4652000000000002 Payment Prove
Payment without knowing what was paid.
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: P
No ChargeItems on payment-prove, the total amount is always zero, a negative payitem of type 4652000000000011 is used to get the sum of PayItems to zero.
Details: GT counters are not raised
4652000000000003 Invoice
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: I
A reference to the ticket can be created by using cbPreviousReceiptNumber in the request.
Detail: GT counters are raised
4652000000000004 Shift Receipt / Grand Total Ticket / Grand Total Invoice: Shift
Sign: Yes
Chain and national numbering: G
Details: Resets the shift-counter, keeps all other counters
4652000000000005 Daily Receipt / Grand Total Ticket / Grand Total Invoice: Daily
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- keeps the shift-counter
4652000000000006 Monthly Receipt / Grand Total Ticket / Grand Total Invoice: Month
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- Adds a monthly-counter to the yearly-counter and then resets the monthly-counter
- keeps the shift-counter
4652000000000007 Yearly Receipt / Grand Total Ticket / Grand Total Invoice: Year
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- Adds a monthly-counter to the yearly-counter and then resets the monthly-counter
- Resets the yearly-counter
- keeps the shift-counter
4652000000000008 Bill
List of ChargeItems to be paid. Used to inform customers about their open ChargeItems. PayItemType 4652000000000011 is used
Sign: Yes
Chain and national numbering: B
Details: GT counters are not raised. When the bill is used, the phrase "document provisoire" is returned with the fiscalisation signature and must be printed on the bill. If bill and payment prove are created, this does not replace a ticket creation. A ticket or an invoice has to be issued to raise turnover and raise the GT counters as well
4652000000000009 Delivery Note
Sign: no
Chain and national numbering: no
465200000000000A Cash pay-in / Cash Deposit
Same handling as payment prove
Chain and national numbering: P
465200000000000B Cash pay-out
Same handling as payment prove
Chain and national numbering: P
465200000000000C Payment transfer
Switch between payment method, e.g. from cash to credit card
Sign: Yes
Chain and national numbering: P
465200000000000D Internal / Material
Sign: No
Chain and national numbering: no
465200000000000E Foreign sales
Same handling as bill. To be used when something sold in an other country.
Sign: Yes
Chain und national numbering: B
465200000000000F Zero-Receipt
Sign: Yes
Chain and national numbering: G
Details: A receipt with empty charge items block ftChargeItem and empty payment block ftPayItem which amounts to a total of "0".
4652000000000010 Start-Receipt
Sign: Yes
Chain and national numbering: G
4652000000000011 Stop-Receipt
Sign: Yes
Chain and national numbering: G
4652000000000012 Protocol / Technical Event Log
Has to be signed
Sign: Yes
Chain and national numbering: L
Details: Can be used by the POS-System to log custom data.
4652000000000013 Protocol / Accounting / Audit
Has to be signed
Sign: Yes
Chain and national numbering: L
Details: Can be used by the POS-System to log custom data.
4652000000000014 Protocol / Custom
Does not need to be signed
Sign: No
Chain and national numbering: No
Details: Can be used by the POS-System to log custom data.
4652000000000015 Archive
Has to be Signed
Sign: Yes
Chain and national numbering: A
Details: Will trigger a daily closing automatically.
Creates an archive starting with the first receipt of the queue (or the last archive receipt) until the last receipt before this request. It must not contain more than 365 days.
To retrieve the export as a zip-file (containing the certificate, ReceiptJournals and QueueItems), a normal /journalrequest has to be sent to the ftJournalType: 4652000000010010. The value of ftQueueRow in the response of this ReceiptCase has to be sent in the from-parameter.
4652000000000016 Copy
Has to be Signed
Sign: Yes
Chain and national numbering: C
Details: in a request the cbPreviousReceiptReference is mandatory. It contains the receipt number which was handed out as a copy, issued by the original cash register. When a copy of a receipt is requested, the phrase "duplicata" is returned with the fiscalisation signature and must be printed on the receipt. Every time the receipt is reprinted, an up-counting number denoting how many times the receipt has been printed, is returned. It must be printed on the receipt and is then recorded in the journal.The layout and the information contained shall be the same as in the original document.

Examples of Usage

fiscalisationData for Cloud REST API and Local Terminal API integrations

For Cloud REST API and P2P(LOCAL Terminal API) integrations, please add fiscalisationData JSON object to the request body. This aproach is valid for both standard and ISV integrations.

    "fiscalisationData": {
        "cbChargeItems": [
            {
                "amount": 1,
                "description": "description 1",
                "position": 1,
                "quantity": 100,
                "unit": "pcs",
                "unitPrice": 1,
                "vatAmount": 1,
                "vatRate": 2400,
                "currencyCode": "978",
                "moment": "2025-04-22T13:53:32.205Z",
                "ftChargeItemCaseData": {
                    "taxable": true
                },
                "ftChargeItemCase": 5139205309155246083
            }
        ],
        "cbPayItems": [
            {
                "amount": 1,
                "description": "Card",
                "position": 1,
                "currencyCode": "978",
                "moment": "2025-04-22T13:53:32.205Z",
                "ftPayItemCase": 5139205309155246085
            }
        ],
        "cbUser": {
            "merchantName": "Merchant",
            "cashier": {
                "name": "John Doe",
                "id": 10
            }
        },
        "cbReceiptMoment": "2025-04-22T13:53:32.205Z",
        "cbReceiptReference": "Unique reference of the receipt",
        "ftReceiptCase": 5139205309155246085,
        "currencyCode": "978"
    }

fiscalisationData for Interapp(app2app) Integration

For Interapp(app2app) integration, you should encode fiscalisationData JSON object as base64 format and pass it as uri parameter

ewogICAgImNiQ2hhcmdlSXRlbXMiOiBbCiAgICAgICAgewogICAgICAgICAgICAiYW1vdW50IjogMSwKICAgICAgICAgICAgImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIDEiLAogICAgICAgICAgICAicG9zaXRpb24iOiAxLAogICAgICAgICAgICAicXVhbnRpdHkiOiAxMDAsCiAgICAgICAgICAgICJ1bml0IjogInBjcyIsCiAgICAgICAgICAgICJ1bml0UHJpY2UiOiAxLAogICAgICAgICAgICAidmF0QW1vdW50IjogMSwKICAgICAgICAgICAgInZhdFJhdGUiOiAyNCwKICAgICAgICAgICAgImN1cnJlbmN5Q29kZSI6ICI5NzgiLAogICAgICAgICAgICAibW9tZW50IjogIjIwMjUtMDQtMjJUMTM6NTM6MzIuMjA1WiIsCiAgICAgICAgICAgICJmdENoYXJnZUl0ZW1DYXNlRGF0YSI6IHsKICAgICAgICAgICAgICAgICJ0YXhhYmxlIjogdHJ1ZQogICAgICAgICAgICB9LAogICAgICAgICAgICAiZnRDaGFyZ2VJdGVtQ2FzZSI6IDUxMzkyMDUzMDkxNTUyNDYwODMKICAgICAgICB9CiAgICBdLAogICAgImNiUGF5SXRlbXMiOiBbCiAgICAgICAgewogICAgICAgICAgICAiYW1vdW50IjogMSwKICAgICAgICAgICAgImRlc2NyaXB0aW9uIjogIkNhcmQiLAogICAgICAgICAgICAicG9zaXRpb24iOiAxLAogICAgICAgICAgICAiY3VycmVuY3lDb2RlIjogIjk3OCIsCiAgICAgICAgICAgICJtb21lbnQiOiAiMjAyNS0wNC0yMlQxMzo1MzozMi4yMDVaIiwKICAgICAgICAgICAgImZ0UGF5SXRlbUNhc2UiOiA1MTM5MjA1MzA5MTU1MjQ2MDg1CiAgICAgICAgfQogICAgXSwKICAgICJjYlVzZXIiOiB7CiAgICAgICAgIm1lcmNoYW50TmFtZSI6ICJNZXJjaGFudCIsCiAgICAgICAgImNhc2hpZXIiOiB7CiAgICAgICAgICAgICJuYW1lIjogIkpvaG4gRG9lIiwKICAgICAgICAgICAgImlkIjogMTAKICAgICAgICB9CiAgICB9LAogICAgImNiUmVjZWlwdE1vbWVudCI6ICIyMDI1LTA0LTIyVDEzOjUzOjMyLjIwNVoiLAogICAgImNiUmVjZWlwdFJlZmVyZW5jZSI6ICJVbmlxdWUgcmVmZXJlbmNlIG9mIHRoZSByZWNlaXB0IiwKICAgICJmdFJlY2VpcHRDYXNlIjogNTEzOTIwNTMwOTE1NTI0NjA4NSwKICAgICJjdXJyZW5jeUNvZGUiOiAiOTc4Igp9

E-commerce

While the Fiscal API is not yet available for web payments, it will be launching soon.

Account Setup

To activate fiscalization for your integration, please contact your sales representative.

Get Support

If you would like to integrate with Viva, or if you have any queries about our products and solutions, please see our Contact & Support page to see how we can help!