The Events and Audits area provides a centralized audit trail of the actions performed by users within the SIBS Backoffice.
Every significant operational and administrative action executed through the Backoffice is recorded in the audit log, allowing authorized users to review historical activity, verify operational changes, and support troubleshooting, operational control, and compliance requirements.
The audit log provides visibility into user activity according to the permissions assigned to each Backoffice profile, ensuring that users can access only the audit information permitted by their role.
The Events and Audits area enables authorized users to:
Review actions executed within the SIBS Backoffice.
Identify the user responsible for each action.
Review when operations were performed.
Verify the type and description of recorded events.
Support operational traceability and accountability.
Accessing Events and Audits
The Events and Audits area is available from the SIBS Backoffice navigation menu.
Selecting Events and Audits displays the audit log associated with the currently selected merchant and the authenticated user’s permissions.
Figure 1 – List of Events and Audits
Audit Visibility
The information available in the audit log depends on the permissions assigned to the authenticated user’s profile.
The following visibility rules apply:
User Profile
Audit Visibility
Owner
Can view all audit records associated with the merchant.
Administrator
Can view audit records generated by users belonging to hierarchically lower profiles.
Supervisor
Can view audit records generated by the supervisor account and by Operator users.
Operator
Can view only the audit records generated by the authenticated user.
These visibility rules ensure that audit information remains accessible only to users with the appropriate authorization level.
Audit Information
Each audit entry records information describing the action performed within the Backoffice.
The following table describes the information available for each audit record.
Field
Description
Severity
Indicates the severity level associated with the recorded action.
Date
Date and time at which the action was executed. For actions performed on the current day, only the time is displayed.
User
E-mail address of the user who executed the action.
Type
Type of operation recorded in the audit log.
Description
Description of the action performed by the user.
The audit information enables authorized users to reconstruct operational activity and identify when, by whom, and how an action was performed.
Viewing Audit Entries
The Events and Audits page displays the recorded events in chronological order, allowing authorized users to review the operational history associated with the selected merchant.
Each entry provides sufficient information to identify:
The user who executed the action.
The type of operation performed.
The execution timestamp.
The severity of the recorded event.
A description of the executed operation.
The audit log is intended to provide operational traceability rather than transaction management. For detailed transaction information, refer to the corresponding transaction management sections of this documentation.
Example: Refund Operation Audit
Operational actions performed within the Backoffice are automatically recorded in the audit log.
For example, when a Refund operation is executed, the corresponding audit entry records information such as:
The user who performed the refund
The merchant associated with the operation
The transaction identifier
The operation details
This information allows authorized users to verify that the operation was executed and identify the user responsible for the action.
Figure 2 – Refund Detail in the List of Events and Audits
Important
The Events and Audits area records operational activity performed through the SIBS Backoffice.
The audit log is intended to provide operational traceability and accountability. It should not be considered a substitute for transaction reporting or reconciliation, which are covered by the corresponding reporting and transaction management features.
The information visible in the audit log depends on the authenticated user’s permissions and the active merchant context.
Permissions
Access to the Events and Audits area is controlled through the SIBS Backoffice permission model.
The audit information available to each user depends on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The operational scope defined for the user within the merchant hierarchy.
As a result, different users may view different audit records while accessing the same Backoffice environment.
The Payment Entity area allows merchants to configure the payment entities available for use within the SIBS Payment Gateway.
A Payment Entity identifies the entity that will be associated with supported payment operations initiated through the SIBS Backoffice. Once configured, the entity becomes available for selection in the corresponding Backoffice features that support Payment Entity selection.
Payment Entities allow merchants to organize and identify payment operations according to their business or operational requirements. Depending on the merchant configuration and enabled services, multiple Payment Entities may be defined and selected when initiating supported payment operations through the SIBS Backoffice or VTerminal.
The Payment Entity area allows authorized users to:
Create a new Payment Entity.
Configure the information associated with a Payment Entity.
Make the configured Payment Entity available for supported payment operations.
Accessing the Payment Entity
The Payment Entity area is available from the SIBS Payment Gateway section of the SIBS Backoffice navigation menu.
Selecting Payment Entity displays the Payment Entity configuration page.
Figure 1 – Payment Entity Submenu
Creating a Payment Entity
To create a new Payment Entity:
Step 1. Open the Payment Entity area.
Step 2. Complete the required information for the new Payment Entity.
Step 3. Review the configured information.
Step 4. Select Confirm to create the Payment Entity.
Figure 2 – Insertion of Payment Entity
After the operation is successfully completed, the configured Payment Entity becomes available for use in the supported SIBS Backoffice payment operations.
Using a Payment Entity
Once a Payment Entity has been configured, it becomes available in the Entity field when initiating payment operations through the vTerminal. The configured Payment Entity can then be selected as part of the payment information associated with the operation.
The availability of Payment Entities depends on the merchant configuration and the services enabled for the merchant account.
Payment Entities are available only to merchants for which the corresponding SIBS Payment Gateway service has been enabled.
Configured Payment Entities remain available for subsequent supported payment operations.
Permissions
Access to the Payment Entity area is controlled through the SIBS Backoffice permission model.
The operations available to each user depend on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The services enabled for the merchant account.
As a result, different users may have access to different Payment Entity operations while using the same Backoffice environment.
The SPG App area allows merchants to manage the application credentials required for integrations with the SIBS Payment Gateway (SPG 2.0).
While the Credentials area manages merchant application credentials associated with merchant profiles and terminals, the SPG App provides access to the OAuth application credentials (Client ID and Client Secret) used by SPG 2.0 applications…
These credentials uniquely identify an application during the authentication process. They are typically configured in server-to-server applications and used during the OAuth authentication process to obtain the Bearer Tokens required for subsequent API requests.
From the SPG App area, authorized users can:
Obtain the Client ID and Client Secret assigned to the merchant application.
View the Client ID associated with an application.
View the corresponding Client Secret.
Retrieve the credentials required by server-to-server integrations.
Access to this functionality is available only to users with the appropriate permissions.
Relationship with API Authentication
The Client ID and Client Secret obtained through the SPG App are fundamental components of the SIBS Payment Gateway authentication model.
Applications use these credentials to authenticate with the SIBS Payment Gateway and obtain a Bearer Token. The Bearer Token is then included in subsequent API requests to authorize access to the services enabled for the merchant.
This chapter describes only the operational management of the application credentials within the SIBS Backoffice.
For a complete description of the authentication process, including Bearer Token generation and authenticated API requests, refer to A.3 – API Requests. For implementation examples using these credentials, refer to the relevant integration chapters in D. Payment Methods and to F.1 – End-to-End Integration Examples.
Accessing the SPG App
The SPG App area is available from the SIBS Payment Gateway section of the SIBS Backoffice navigation menu.
Selecting SPG App displays the application credential management page.
Figure 1 – Getting a Client ID and a Client Secret in the SPG App
Generating Application Credentials
The SPG App allows authorized users to obtain the Client ID and Client Secret associated with the merchant application.
To obtain the application credentials assigned to the merchant application:
Step 1. Open the SPG App area.
Step 2. Select the option to obtain the application credentials.
Before completing the operation, the Backoffice requests confirmation of the authenticated user’s identity.
Figure 2 – Enter Password to Confirm the Operation in the SPG App
Step 3. Enter the account password.
Step 4. Confirm the operation.
After successful confirmation, the Client ID and Client Secret associated with the merchant application are displayed.
Viewing the Client ID and Client Secret
The SPG App allows authorized users to display the application credentials associated with the merchant account.
Because these credentials provide access to the authentication process, the Backoffice requires password confirmation before displaying them.
To view the application credentials:
Step 1. Open the SPG App area.
Step 2. Select the option to view the application credentials.
Figure 3 – Enter Password to View Client ID and Client Secret in the SPG App
Step 3. Enter the account password.
Step 4. Confirm the operation.
The Backoffice displays the Client ID and Client Secret associated with the merchant application.
Figure 4 – View Client ID and Client Secret in the SPG App
These credentials are subsequently used during the authentication process to obtain Bearer Tokens for authenticated requests to the SIBS Payment Gateway APIs.
Important
The Client ID and Client Secret displayed in the SPG App are application credentials and must be stored securely and must never be exposed in client-side applications, browser code, or publicly accessible repositories.
These credentials are distinct from:
Bearer Tokens, which are short-lived authentication tokens obtained using the Client ID and Client Secret.
Payment card tokens, which identify tokenized payment cards and are managed through G.1.7.4 – Token Management.
Although these elements all participate in the SIBS Payment Gateway ecosystem, they serve different purposes within the overall security and payment architecture.
Permissions
Access to the SPG App area is controlled through the SIBS Backoffice permission model.
The SPG App operations available to each user depend on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The SPG App service being enabled for the merchant account.
As a result, different users may have access to different SPG App operations while using the same Backoffice environment.
The Token Management area allows merchants to manage payment card tokens generated during SIBS Payment Gateway payment operations that support card tokenization.
Card tokenization replaces sensitive payment card information with a unique token that can subsequently be used to identify the underlying payment instrument without exposing the original card data. This mechanism enables applications to perform subsequent payment operations without storing sensitive card information, helping reduce the handling of cardholder data.
From the Token Management area, authorized users can:
View the card tokens generated by the SIBS Payment Gateway.
Review the tokens associated with the selected merchant.
Remove tokens that are no longer required.
Token management is performed exclusively through the SIBS Backoffice and is available only to users with the appropriate permissions.
Relationship with Payment Tokenization
Payment card tokens are automatically generated by the SIBS Payment Gateway during payment operations that support card tokenization. Once created, these tokens become available in the Token Management area for operational management.
These tokens uniquely identify the associated payment card while preventing applications from storing or processing the original card number.
This chapter describes the operational management of generated tokens from the SIBS Backoffice.
The functional use of payment card tokens during payment operations depends on the integration model and payment method being implemented. Detailed implementation examples are provided in D. Payment Methods, while complete transaction scenarios using tokenized payments are illustrated in F.1 – End-to-End Integration Examples.
Accessing Token Management
The Token Management area is available from the SIBS Payment Gateway section of the SIBS Backoffice navigation menu.
Selecting Token Management displays the list of payment card tokens associated with the currently selected merchant.
Figure 1 – List of Tokens Generated by the SPG
Viewing Generated Tokens
The Token Management page provides a consolidated view of all payment card tokens generated by the SIBS Payment Gateway for the selected merchant.
Each entry represents a payment card that has been tokenized by the SIBS Payment Gateway. The generated token may subsequently be referenced by supported payment operations that allow the reuse of previously tokenized payment cards.
The Backoffice allows authorized users to review the tokens currently associated with the merchant account.
Token List
The token list displays the payment card tokens currently managed by the SIBS Payment Gateway.
Depending on the merchant configuration and the payment operations performed, multiple payment card tokens may be available for consultation.
The list allows merchants to identify the payment card tokens currently stored by the SIBS Payment Gateway and available for supported payment operations.
Removing a Token
Payment card tokens that are no longer required can be removed from the Backoffice.
Removing an existing payment card token permanently deletes the token from the merchant’s token repository. After removal, the token can no longer be referenced by supported payment operations.
To remove a token:
Step 1. Locate the required payment card token.
Step 2. Open the Options menu (three vertical dots).
Step 3. Select Delete.
Confirm the operation when prompted.
After confirmation, the selected payment card token is removed from the merchant’s token list.
Important
Payment card tokens managed from the Token Management area are distinct from the Bearer Tokens used for API authentication.
Payment card tokens identify tokenized payment cards and are generated as part of supported payment operations.
Bearer Tokens authenticate applications when invoking the SIBS Payment Gateway APIs and are obtained through the authentication process described elsewhere in this documentation.
Although both are commonly referred to as tokens, they serve entirely different purposes within the SIBS Payment Gateway architecture.
Permissions
Access to the Token Management area is controlled through the SIBS Backoffice permission model.
The token management operations available to each user depend on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The Token Management service being enabled for the merchant account.
As a result, different users may have access to different token management operations while using the same Backoffice environment.
The Credentials area allows merchants to manage the application credentials used by the SIBS Payment Gateway.
Application credentials provide the identity used by applications and server-to-server integrations when authenticating with the SIBS Payment Gateway APIs. During the authentication process, these credentials are used to obtain a Bearer Token, which is subsequently included in API requests as described in A.3 – API Requests and the integration chapters of D. Payment Methods.
Each credential is associated with a specific merchant profile and terminal, ensuring that applications can authenticate only for the services and resources enabled for the corresponding merchant account.
From the Credentials area, authorized users can:
View existing credentials.
Create new application credentials.
Review credential information.
View credential details.
Remove credentials that are no longer required.
Credential management is performed exclusively through the SIBS Backoffice and is available only to users with the appropriate permissions.
Relationship with API Authentication
Credential management is an operational function of the SIBS Backoffice that complements the API authentication model described throughout this documentation.
When implementing a server-to-server integration, an application uses the credentials created in this area to authenticate with the SIBS Payment Gateway and obtain a Bearer Token. That Bearer Token is then included in subsequent API requests to authorize access to the SIBS Payment Gateway services.
This chapter focuses exclusively on the operational management of credentials within the Backoffice.
For a complete description of the authentication flow, including Bearer Token generation and API authentication, refer to the authentication and integration chapters referenced in Related Topics.
Accessing Credentials
The Credentials area is available from the SIBS Payment Gateway section of the SIBS Backoffice navigation menu.
Selecting Credentials displays the list of credentials associated with the currently selected merchant.
Figure 1 – Credentials List
Viewing Credentials
The Credentials page provides a consolidated view of all credentials associated with the selected merchant.
Each credential represents the identity of an application that authenticates with the SIBS Payment Gateway APIs.
The list provides summary information that allows authorized users to identify the credential, verify its operational status, and confirm the associated merchant profile and terminal.
Credential List Fields
The following table describes the information displayed for each credential.
Field
Description
Credential
Logical name assigned to the credential for identification purposes.
Profile
Merchant profile associated with the credential.
Terminal
Terminal associated with the credential.
Expiration Date
Date on which the credential expires.
Status
Indicates the operational status of the credential. Active credentials are displayed with a green status indicator, while inactive credentials are displayed with a red status indicator.
Creating a Credential
New credentials can be created directly from the Credentials area.
Credentials are typically created whenever a new application, service, or server-to-server integration requires independent authentication with the SIBS Payment Gateway.
To create a new credential:
Step 1. Open the Credentials menu.
Step 2. Select Add Credential
Figure 2 – “Add Credential”
The Backoffice displays the credential creation form.
Figure 3 – Form to Add a Credential
All fields in the form are mandatory.
Credential Creation Fields
The following table describes the information required to create a new credential.
Field
Description
Credential
Logical name assigned to the credential for identification purposes.
Profile
Merchant profile associated with the credential.
Terminal
Terminal associated with the credential.
To complete the operation:
Step 3. Enter the required information.
Step 4. Select Confirm.
Alternatively, select Clear to remove all information entered in the form.
The Backoffice displays a confirmation screen before creating the credential.
Figure 4 – Confirmation of Created Credential
Step 5. Confirm the operation.
After the operation is completed successfully, the Backoffice displays a confirmation message containing the newly generated credential together with its corresponding expiration date.
Figure 5 – Generated Credential
The newly created credential becomes immediately available in the Credentials list.
Video Tutorial – Configuring Credentials
The following video demonstrates how to create and configure a credential in the SIBS Backoffice, including selecting the merchant profile and terminal and completing the credential creation process.
Video – Configuring Credentials
Viewing Credential Information Summary
The Backoffice allows users to display a summary of the information associated with an existing credential.
To display the summary:
Step 1. Locate the required credential.
Step 2. Select the Expand button displayed at the end of the corresponding row.
The Backoffice expands the selected credential and displays its summary information.
Figure 6 – Credential Information Summary
The summary provides a quick operational view of the credential without requiring access to its detailed information.
Viewing Credential Details
Detailed information about a credential can be accessed directly from the Credentials list.
This functionality allows authorized users to inspect the complete information associated with a credential and verify the generated credential.
To view the credential details:
Step 1. Locate the required credential.
Step 2. Open the Options menu (three vertical dots).
Step 3. Select Details.
Figure 7 – View Credential Details
For security reasons, the Backoffice requests the authenticated user’s password before displaying the credential information.
Figure 8 – Entering the Password to View the Credential Details
Step 4. Enter the account password.
Step 5. Select Confirm.
The Backoffice displays the complete credential details together with the generated credential.
Figure 9 – View Generated Credential
The information displayed in this screen allows authorized users to verify the credential associated with a particular application or integration. These credentials are subsequently used during the authentication process to obtain the Bearer Tokens required for authenticated requests to the SIBS Payment Gateway APIs.
Removing a Credential
Credentials that are no longer required can be removed from the Backoffice.
Removing unused credentials is recommended to help maintain proper control over the credentials associated with applications and integrations.
To remove a credential:
Step 1. Locate the required credential.
Step 2. Open the Options menu (three vertical dots).
Step 3. Select Remove Credential.
Figure 10 – Remove Credential
For security reasons, the Backoffice requests the authenticated user’s password before completing the operation.
Figure 11 – Enter the Password to Confirm the Credential Removal
Step 4. Enter the account password.
Step 5. Confirm the operation.
After confirmation, the selected credential is permanently removed from the merchant’s credential list.
Important
Credential management in the SIBS Backoffice complements the API authentication model described throughout this documentation.
This chapter explains how credentials are created, inspected, and managed from an operational perspective. The complete authentication process – including the generation of Bearer Tokens and their use in authenticated API requests – is described in A.3 – API Requests. For implementation examples showing authenticated SPG API calls, refer to the relevant payment method integration chapters in D. Payment Methods or to F.1 – End-to-End Integration Examples.
Permissions
Access to the Credentials area is controlled through the SIBS Backoffice permission model.
The credential management operations available to each user depend on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The Credentials service being enabled for the merchant account.
As a result, different users may have access to different credential management operations while using the same Backoffice environment.
The Static QR Codes area allows merchants to create, manage, and monitor Static QR Codes associated with products and services available through the SIBS Payment Gateway.
A Static QR Code enables consumers to perform purchase transactions using the MB WAY application or participating banking applications by scanning a QR Code associated with a predefined product, merchant, and fixed amount.
Depending on the QR Code type, the payment process may optionally collect additional information from the consumer during the purchase operation.
The Static QR Codes functionality is available only for merchants who have subscribed to this service through their Financial Institution.
Accessing Static QR Codes
The Static QR Codes area is available from the SIBS Payment Gateway section of the SIBS Backoffice navigation menu.
Merchants who have subscribed to the Static QR Codes service can access all QR Code management operations from this menu.
Figure 1 – Onboarding in Static QR Code feature
Creating Static QR Codes
New Static QR Codes are created directly from the Static QR Codes area of the SIBS Backoffice.
To create a new Static QR Code:
Step 1. Open the Static QR Codes menu.
Step 2. Select Create QR Code.
Figure 2 – “Create QR Code”
The Backoffice displays the QR Code creation form.
Two types of Static QR Codes are supported:
Type 1 – Purchase operation without information collection.
Type 2 – Purchase operation with information collection.
Type 1 – Purchase without Information Collection
Type 1 Static QR Codes are intended for purchase operations where no additional customer information is collected during the payment process.
Figure 3 – Create a Static QR Code for a Purchase without data collection
Type 2 – Purchase with Information Collection
Type 2 Static QR Codes allow the merchant to request additional information from the customer during the payment process.
Figure 4 – Create a Static QR Code for a Purchase with data collection
Static QR Code Creation Fields
The QR Code creation form contains two categories of information:
Internal information used by the merchant for product and inventory management.
Information displayed to the consumer during the MB WAY payment experience.
The internal information is intended exclusively for merchant administration and is not presented to the consumer during the payment process.
Internal Information Fields
The following table describes the merchant-only fields available during Static QR Code creation.
Field
Required
Description
SIBS Payment Gateway Terminal
Mandatory
Identifies the SIBS Payment Gateway terminal associated with the QR Code. When multiple terminals exist, the appropriate terminal can be selected.
QR Code Type
Mandatory
Defines whether the QR Code is created as Type 1 (without information collection) or Type 2 (with information collection).
Internal Product Description
Mandatory
Internal product description used by the merchant for identification and management purposes.
Initial Stock
Optional
Initial quantity available for the associated product.
QR Code Expiration Date
Optional
Defines the QR Code expiration date. When omitted, the maximum supported validity period (10 years) is applied.
Consumer-visible Fields – Type 1
For Type 1 Static QR Codes, the following information may be presented to the consumer during the MB WAY payment flow.
Field
Required
Description
Company Name to Display
Optional
Merchant commercial name displayed to the consumer.
Model and Product Name
Mandatory
Product name presented during the payment process.
Information to Collect
Mandatory
Defines the information elements that the merchant may request from the consumer during the purchase process, including the Tax Identification Number (TIN) and delivery information, when applicable. The TIN remains optional for the consumer even when this option is enabled.
Customer Support Contact
Optional
Merchant support contact information (telephone number or e-mail address).
Sales Amount
Mandatory
Fixed purchase amount associated with the QR Code.
Consumer-visible Fields – Type 2
For Type 2 Static QR Codes, additional information can be collected during the payment process.
Field
Required
Description
Company Name to Display
Optional
Merchant commercial name displayed to the consumer.
Model and Product Name
Mandatory
Product name displayed in the MB WAY application.
Customer Support Contact
Optional
Merchant support contact information.
Sales Amount
Mandatory
Fixed purchase amount associated with the QR Code.
Delivery Value
Optional
Delivery amount associated with the purchase, when applicable.
Terms and Conditions Link
Optional
URL directing the consumer to the merchant’s terms and conditions.
Purchase Status Notification
Optional
Defines how the consumer will be notified about the purchase status. Available options include “Do not notify“, “E-mail“, “SMS“, and “Phone call“.
Notification E-mail Address
Optional
Specifies the e-mail address used for purchase status notifications, when applicable.
Managing Product Stock
Static QR Codes may optionally include inventory control. When stock management is enabled during Static QR Code creation, the merchant specifies the initial stock quantity. As purchases are completed using the Static QR Code, the available stock is automatically decreased, allowing the remaining inventory to be tracked directly from the SIBS Backoffice.
When stock management is enabled, merchants can adjust the available quantity directly from the Static QR Code list.
To manage product stock:
Step 1. Locate the required Static QR Code.
Step 2. Select Manage Stock.
Figure 5 – “Manage stock” of products associated to a Static QR Code
The stock management screen is displayed.
Figure 6 – Edit the stock of a product associated to a Static QR Code
Step 3. Use the + and − controls to increase or decrease the available stock according to the required inventory adjustment. The resulting quantity is automatically reflected in the Available Stock field.
Figure 7 – Add or decrease available stock
After confirmation, the updated stock quantity becomes immediately available for subsequent payment operations.
Viewing Static QR Codes
After a Static QR Code has been created, it is displayed in the Static QR Codes list.
The list provides a consolidated view of all Static QR Codes associated with the selected merchant. Users can search for specific QR Codes using the available Quick Filters, allowing the list to be filtered according to the characteristics of the registered Static QR Codes.
Figure 8 – Static QR Code List
Figure 8 illustrates the Static QR Codes list presented in the Backoffice. The information displayed for each Static QR Code is described below.
Static QR Code List Fields
The following table describes the information displayed for each Static QR Code.
Field
Description
Status
Indicates the current status of the Static QR Code. Possible values are Active, Inactive, and Suspended by SIBS.
ID
Internal product identifier associated with the Static QR Code.
With Information Collection
Indicates whether the QR Code collects additional information from the consumer. Possible values are Yes and No.
Description
Product description presented to the consumer during the payment process.
Amount
Fixed purchase amount associated with the Static QR Code.
Delivery Value
Delivery cost associated with the purchase, when applicable.
Available Stock
Current quantity of products available for sale.
Expiration Date
Date on which the Static QR Code expires.
Creation Date
Date on which the Static QR Code was created.
Downloading Static QR Codes
The Backoffice allows merchants to download individual or multiple Static QR Codes.
Downloading a Single Static QR Code
To download a Static QR Code:
Step 1. Locate the required Static QR Code.
Step 2. Open the Options menu.
Step 3. Select Download.
Figure 9 – Download Static QR Code
The Backoffice downloads a ZIP archive containing:
The product’s internal description.
A PNG image containing:
Company name to display.
Model and product name.
Information to collect.
Customer support contact.
Sales amount.
A Static QR Code can only be downloaded after all mandatory fields have been completed.
Downloading Multiple Static QR Codes
Multiple Static QR Codes can be downloaded simultaneously.
To download multiple QR Codes:
Step 1. Select the required Static QR Codes.
Step 2. Open the More Options menu (three vertical dots).
Step 3. Select Download Selected.
Figure 10 – Download Multiple Static QR Codes
The selected Static QR Codes are downloaded in a single ZIP archive containing one PNG image for each selected QR Code.
Editing Static QR Codes
Authorized users can update information associated with an existing Static QR Code.
The following information can be modified:
Status.
Available stock (when stock management is enabled).
QR Code expiration date.
Model and product name.
Terms and Conditions link.
Customer support contact.
Sales amount.
Delivery value (Type 2 QR Codes only).
Editing a Type 1 Static QR Code
To edit a Type 1 Static QR Code:
Step 1. Locate the required QR Code.
Step 2. Open the Options menu.
Step 3. Select Detail/Edit.
Figure 11 – Edit a Static QR Code of Type 1
Update the required information and save the changes.
Editing a Type 2 Static QR Code
Type 2 Static QR Codes are edited using the same procedure.
The edit form additionally allows modification of the delivery value and other fields specific to QR Codes with information collection.
Figure 12 – Edit a Static QR Code of Type 2
Deactivating Static QR Codes
When a Static QR Code is deactivated, it can no longer be used to perform payment operations.
Deactivating a Single Static QR Code
To deactivate a Static QR Code:
Step 1. Locate the required Static QR Code.
Step 2. Open the Options menu.
Step 3. Select Deactivate.
Figure 13 – Deactivate a Static QR Code
A confirmation dialog is displayed showing:
Purchase amount.
Product description.
QR Code creation date.
Figure 14 – Confirm a Static QR Code Deactivation
Step 4. Confirm the operation.
After confirmation, the Static QR Code becomes unavailable for future payment operations.
Deactivating Multiple Static QR Codes
The Backoffice also supports bulk deactivation.
To deactivate multiple Static QR Codes:
Step 1. Select the required Static QR Codes.
Step 2. Open the More Options menu (three vertical dots).
Step 3. Select Deactivate Selected.
Figure 15 – Deactivate Multiple Static QR Codes
A confirmation screen displays all selected Static QR Codes.
Figure 16 – Confirm Deactivation of Multiple Static QR Codes
Step 4. Confirm the operation.
All selected Static QR Codes are deactivated simultaneously.
Viewing Transactions Associated with a Static QR Code
The SIBS Backoffice allows users to review all transactions associated with a specific Static QR Code.
To display the transactions associated with a Static QR Code:
Step 1. Locate the required Static QR Code in the Static QR Codes list.
Step 2. Select the corresponding Static QR Code entry.
The Backoffice automatically redirects the user to the Transactions area, displaying the operations associated with the selected Static QR Code.
Figure 17 – Inquire a Static QR Code’s Operations in the Transaction List
The transaction list displays all operations associated with the selected Static QR Code.
Figure 18 – List of Operations Associated to a Given Static QR Code
Users can then inspect each transaction using the standard transaction management functionality described in G.1.4 – Transaction Management.
Refunding Static QR Code Purchases
Purchases performed using Static QR Codes can be refunded directly from the associated transaction list.
To initiate a refund:
Step 1. Locate the transaction to be refunded.
Step 2. Open the Options menu (three vertical dots).
Step 3. Select Refund.
Figure 19 – Refund of a Purchase with Static QR Code
The refund screen is displayed.
Figure 20 – Enter Refund Amount of a Purchase with a Static QR Code
Step 4. Enter the refund amount.
The Backoffice supports both:
Full refunds, by entering the complete purchase amount.
Partial refunds, by entering a lower amount.
Step 5. Confirm the refund operation.
Searching for Static QR Code Transactions
The SIBS Backoffice allows users to search for transactions associated with Static QR Codes by using the available transaction filters.
To search for Static QR Code transactions:
Step 1. Open the Transactions area.
Step 2. Expand Other Filters.
Step 3. Select the Static QR Code filter.
Figure 21 – Static QR Code Search Filter
The Payment Method filter can also be used to further refine the search results.
Figure 22 – Select “Payment Method” through the “Other Filters” Option
Combining multiple filters allows users to narrow the list of transactions according to the selected search criteria.
Importing Static QR Codes
The Backoffice supports the bulk creation of Static QR Codes by importing data from a CSV file.
This functionality simplifies the registration of multiple Static QR Codes by allowing merchants to upload product information in a single operation using a CSV file that follows the format supported by the SIBS Backoffice.
To import Static QR Codes:
Step 1. Open the Static QR Codes area.
Step 2. Select Import QR Codes.
Figure 23 – Import QR Codes
The Backoffice displays the import interface.
Step 3. Select the CSV file containing the Static QR Code information.
Figure 24 – Import QR Codes via CSV File
Step 4. Confirm the import operation.
The Backoffice validates the uploaded file and creates the corresponding Static QR Codes using the information contained in the CSV file.
Permissions
Access to the Static QR Codes area is controlled through the SIBS Backoffice permission model.
The Static QR Code functionality available to each user depends on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The Static QR Codes service being enabled for the merchant account.
As a result, different users may have access to different Static QR Code operations while using the same Backoffice environment.
The Recurring Payments area provides access to recurring payment agreements associated with the selected merchant.
Authorized users can view registered recurring payments, consult their operational status, remove active recurring payments, review the transactions associated with a recurring payment, and inspect the detailed information available for each recurring payment.
Recurring Payments are available only for merchants with the corresponding SIBS Payment Gateway service enabled.
Accessing Recurring Payments
Recurring Payments are available from the SIBS Payment Gateway section of the SIBS Backoffice navigation menu.
Selecting Recurring Payments displays the list of recurring payments associated with the currently selected merchant.
Figure 1 – Merchant’s “Recurring Payments” list
Figure 1 illustrates the Recurring Payments list presented in the Backoffice. The information displayed for each recurring payment is described below.
Viewing Recurring Payments
The Recurring Payments page displays all recurring payment agreements associated with the selected merchant.
The following table describes the information displayed for each recurring payment in the Recurring Payments list.
Field
Description
Amount
Total amount associated with the recurring payment.
Terminal
Terminal where the recurring payment was registered.
Operation Type
Indicates whether the recurring payment was created as an Authorisation or a Purchase.
Frequency
Frequency configured for the recurring payment.
Start Date
Date on which the recurring payment becomes active.
Expiration Date
Date on which the recurring payment expires.
Last 4 PAN Digits
Displays the last four digits of the payment card associated with the recurring payment.
Status
Indicates whether the recurring payment is Active or Inactive.
By default, only Active recurring payment records are displayed.
The list provides a consolidated operational view of all recurring payment agreements currently available for the selected merchant.
Removing a Recurring Payment
Authorized users can deactivate an active recurring payment directly from the recurring payments list.
To remove a recurring payment:
Step 1. Locate the required recurring payment.
Step 2. Select the Delete (dustbin) icon associated with the recurring payment.
Figure 2 – Remove a Recurring Payment
A confirmation dialog is displayed.
Figure 3 – Confirm the removal of a Recurring Payment
Step 3. Confirm the operation.
After confirmation, the recurring payment is removed from the list of active recurring payments.
Viewing Transactions Associated with a Recurring Payment
The Backoffice allows users to review the transactions associated with a recurring payment.
To display the associated transactions:
Step 1. Locate the required recurring payment.
Step 2. Select the recurring payment entry.
Figure 4 – Check for transactions associated with the Recurring Payment
The Backoffice displays the transactions associated with the selected recurring payment.
By default, the list contains the transactions processed during the previous seven days.
Figure 5 – List of transactions associated with a Recurring Payment
Recurring transactions are identified in the transaction list by the recurring transaction indicator.
This indicator allows users to distinguish recurring payment transactions from standard payment transactions directly within the transaction list.
Viewing Recurring Payment Details
Detailed information about a recurring payment can also be accessed from the Transactions area of the Backoffice.
To view the recurring payment details from a transaction:
Step 1. Open the Transactions menu.
Step 2. Locate the transaction associated with the recurring payment.
Step 3. Open the Options menu.
Step 4. Select the recurring payment details.
Figure 6 – “Recurring Payment” detail in the “Transactions” menu
The detailed recurring payment information is displayed.
Figure 7 – Recurring Payment’s detail
The Backoffice also provides a consolidated overview of the recurring payment.
Figure 8 – Recurring Payment’s overview
Permissions
Access to the Recurring Payments area is controlled through the SIBS Backoffice permission model.
The recurring payments available to each user depend on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The Recurring Payments service being enabled for the merchant account.
As a result, different users may have access to different recurring payment information while using the same Backoffice environment.
The Payment Gateway Services area provides access to operational services available for merchants using the SIBS Payment Gateway.
Depending on the authenticated user’s permissions and the services enabled for the merchant account, this area allows users to consult and manage recurring payments, static QR Codes, credentials, token management, and SPG App services.
The availability of individual services depends on the merchant configuration, the services contracted for the merchant account, and the permissions assigned to the authenticated user.
Payment Gateway Services
The Payment Gateway Services module centralizes the operational services provided by the SIBS Payment Gateway.
Depending on the enabled services, users may have access to functionality related to:
Recurring Payments
Static QR Codes
Credentials
Token Management
SPG App
Payment Entity
Some services are available only if they have been enabled for the merchant account.
Accessing Payment Gateway Services
Payment Gateway Services are available from the SIBS Payment Gateway section of the SIBS Backoffice navigation menu.
The services displayed depend on both the merchant configuration and the permissions assigned to the authenticated user.
Permissions
Access to Payment Gateway Services is controlled through the SIBS Backoffice permission model.
The services available to each user depend on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The services enabled for the merchant account.
As a result, different users may have access to different Payment Gateway services while using the same Backoffice environment.
Operational Context
Payment Gateway Services complement the operational capabilities available throughout the SIBS Backoffice.
While Dashboard and Analytics, Transaction Management, Reporting, and Merchant Configuration focus on monitoring, administration, and operational management, the Payment Gateway Services area provides access to service-specific functionality associated with SIBS Payment Gateway products.
The detailed operational procedures for each available service are described in the following sections of this chapter.
Service Coverage
The Payment Gateway Services section includes detailed documentation for the following operational areas:
The User Administration area allows authorized users to manage SIBS Backoffice user accounts associated with the merchant.
Depending on the authenticated user’s permissions, this area provides functionality to view registered users, create new user accounts, assign profiles, configure merchant and store access, associate POS terminals, and update existing user information.
Access to User Administration is restricted to users with the appropriate administrative permissions.
Accessing User Administration
User Administration is available from the Configuration section of the SIBS Backoffice navigation menu.
Selecting Users displays the list of users associated with the current merchant.
Figure 1 – User Status
Viewing Users
The Users page displays all user accounts registered for the selected merchant.
The list includes summary information for each user, such as:
Status
User
Profile
Mobile Phone
User status is represented by coloured indicators that identify the current status of each account, allowing administrators to quickly identify the operational state of registered users.
Depending on the authenticated user’s permissions, only users belonging to the selected merchant are displayed.
Creating a New User
Authorized users can create new SIBS Backoffice user accounts.
To create a new user:
Step 1. Select Add User.
Figure 2 – Add a New User
The New User form is displayed.
Figure 3 – Form to add a New User
Complete all mandatory fields, including:
Name
E-mail address
Mobile phone
Assigned profile
Stores
Associated POS terminals (optional, when applicable)
The assigned profile determines the permissions available to the new user.
Stores can be assigned directly, and individual POS terminals may also be associated by selecting a store and then choosing the required terminals.
SIBS Backoffice does not impose a limit on the number of registered users.
Step 2. Review the user information.
Step 3. Submit the new user.
After the account is created, the new user receives an SMS containing a temporary activation code.
Figure 4 – Login of the new SIBS Backoffice User
During the first login, the user must confirm the activation code and define a new password before accessing the Backoffice.
Figure 5 – Change the password after the first login
A single Backoffice user can be associated with multiple merchants belonging to the same merchant group.
To create a user with merchant group access:
Step 1. Select Add User.
Step 2. Complete the user information.
Step 3. In the Add Merchant section, select all merchants that should be associated with the user.
Step 4. Submit the new user.
Figure 6 – Add User with Merchant Group View
If an existing user is associated with additional merchants, SIBS Backoffice sends an e-mail notification informing the user of the updated merchant associations.
Searching for Users
The Users page provides Quick Filters that allow users to efficiently locate registered user accounts.
Users can search using information contained in the user record.
Up to three filter parameters can be applied simultaneously.
To clear a filter, select the X icon associated with the filter parameter.
Figure 7 – User Quick Filters
Editing User Information
Authorized users can update the information associated with existing Backoffice users.
To edit a user:
Step 1. Locate the required user.
Step 2. Open the Options menu.
Step 3. Select Edit.
Figure 8 – Edit User Data
The Edit User page is displayed.
Figure 9 – Edit User Details
The following information can be updated:
Mobile phone
Assigned profile
Associated merchants
Assigned stores
Associated POS terminals
The user’s registered e-mail address cannot be modified.
If the mobile phone number is changed, a validation code is sent to the new mobile number to complete the update.
Step 4. Save the changes.
User Profiles and Permissions
The permissions available to each Backoffice user are determined by the assigned user profile.
Profiles define the operational areas, configuration menus, reporting capabilities, and administrative functions available within the platform.
When creating or editing users, administrators should assign only the permissions required for the user’s operational responsibilities.
If a user is unable to access the SIBS Backoffice because the password has been forgotten or needs to be reset, the password reset process can be initiated from the Backoffice login page.
Step 1. Open the SIBS Backoffice login page.
Step 2. Select Forgot your password?.
Step 3. Enter the e-mail address associated with the user account.
Step 4. Follow the instructions provided to reset the password.
After the password reset request is validated, the user can define a new password and regain access to the Backoffice.
The Terminal Configuration section provides access to the management of the merchant’s payment terminals and their associated operational configuration.
Depending on the authenticated user’s permissions, this area allows users to consult terminal information, request new terminals, configure the operations available on a terminal, edit terminal information, and consult payment entities associated with the merchant account and submit requests for new payment entities.
The availability of individual features depends on the permissions assigned to the authenticated user and the services enabled for the merchant.
Accessing Merchant Configuration
Merchant Configuration is available from the Configuration section of the SIBS Backoffice navigation menu.
Selecting Terminals displays the list of terminals associated with the currently selected merchant.
Figure 1 – Terminal data
Viewing Terminals
The Terminals page displays all payment terminals associated with the selected merchant.
The information presented for each terminal allows users to identify the available payment infrastructure and serves as the starting point for terminal management operations.
Depending on the authenticated user’s permissions, only the terminals available for the selected merchant are displayed.
Searching for Terminals
The Terminals page provides quick filters that allow users to locate specific terminals.
The available filters can be used to narrow the displayed list and simplify the identification of individual terminals.
Figure 2 – Terminal quick filters
Requesting a New Terminal
The Backoffice allows authorized users to request the creation of a new payment terminal.
To request a new terminal:
Step 1. Open the Options menu.
Step 2. Select Request New Terminal.
The request form is displayed.
Figure 3 – Form to request a new terminal
Complete the required information for the new terminal.
During the request process, users can specify the operations that will be available for the terminal.
Figure 4 – Choose Operations to be allowed in the new terminal
Step 3. Review the terminal configuration.
Step 4. Submit the request.
Viewing Terminal Details
After submitting the terminal request, the Backoffice displays the terminal details page, where users can review the configuration and consult the operational information associated with the newly created terminal.
The terminal details page displays the configuration and operational information associated with the selected terminal.
When required, users can use the available quick filters to locate specific information within the terminal details.
Figure 5 – Quick filters in the new terminal’s detail
Editing the Terminal Name
Authorized users can update the descriptive name of an existing terminal.
To edit the terminal name:
Step 1. Open the required terminal.
Step 2. Select the option to edit the terminal name.
Step 3. Enter the new terminal name.
Step 4. Save the changes.
Figure 6 – Edit the terminal name
Requesting a New Payment Entity
The Payment Entities option allows authorized users to consult the payment entities associated with the merchant account and submit requests for new payment entities.
Depending on the merchant configuration and enabled services, users can access the Payment Entity area to consult the available payment entities and submit requests for new payment entities.
To request a new Payment Entity:
Step 1. Open the Payment Entities menu.
Step 2. Select Request New Payment Entity.
Step 3. Complete the required information.
Step 4. Submit the request.
Figure 7 – Request a new Payment entity
Permissions
Access to terminal management and payment entity configuration is controlled through the SIBS Backoffice permission model.
The operations available to each user depend on:
The authenticated user’s profile.
The permissions assigned to that profile.
The currently selected merchant.
The services enabled for the merchant account.
As a result, different users may have access to different terminal management and payment entity configuration features while using the same Backoffice environment.
