Do not enter the same amount twice, and do not mark an order as paid without confirmation. OmEs Pay checks which local interface or cloud API your point-of-sale system, terminal, and payment partner support, and builds the payment flow around clear statuses and secure access.
The sales amount is automatically sent from the cash register to the terminal, provided the integration supports this.
The cash register or application receives a result and can update the sale or order correctly.
We select the supported protocol that is compatible with your network, hardware, and software architecture.
API keys and credentials are restricted, protected, and periodically renewed in accordance with the provider's capabilities.
In a traditional linked payment, the POS system generates a payment request that includes the amount and a reference. The terminal processes the payment and returns a result. The POS system then processes the result as successful, declined, canceled, or unknown, according to the integration logic.
That sounds simple, but the exceptions determine the quality. What happens in the event of a timeout, network outage, or restart? Can the application retrieve the final status again? How do you prevent the same sale from being paid for twice? These scenarios are part of the delivery process.
A local interface communicates within the network or directly with the terminal. Many point-of-sale systems use recognized protocols or vendor-specific connectors. A cloud API allows an application to initiate transactions and receive status updates through the payment environment, which can also be suitable for e-commerce, apps, or central platforms.
The best choice is determined by official support. A custom integration built around a consumer app or screen automation is not a reliable payment architecture.
An API key identifies or authenticates an application with a service. You’ll also need endpoints, permissions, credentials, error codes, webhooks, a test environment, and lifecycle management. Some providers use different credentials or an OAuth flow instead of a single static key.
Keys should never be hardcoded in publicly accessible website code, shared documents, or emails. Store them in a secret manager or secure server configuration, restrict access, and rotate them when an employee or vendor leaves.
Customers can pay via Bancontact, but the technical integration is typically handled by your terminal provider, acquirer, payment service provider, or gateway. The same integration can process multiple activated payment methods. Which methods are available is determined by your contract and your terminal or online configuration.
Therefore, do not phrase the website as if OmEs pay were issuing a general “Bancontact API key.” OmEs pay helps set up the supported provider integration and determines which payment methods are activated.
Inquire about supported terminal models, POS versions, countries, payment methods, and certifications. Take firmware and API versions into account. A combination that works today must also have a maintenance and update path.
OmEs pay identifies the parties involved and defines their responsibilities. For custom solutions, the software developer remains responsible for their code; OmEs pay supports the provided terminal and provider configuration and the agreed-upon integration test.
The POS system, terminal, provider, network, and developer are listed along with their current versions.
We only use supported protocols, connectors, plugins, or APIs.
Access will be restricted, and test transactions will remain separate from production.
Success, error, timeout, refund, and recovery are walked through in a practical manner.
Let OmEs pay evaluate your existing or planned integration. We combine compatibility, payment partners, security, and status processing into a concrete technical approach.
A POS integration allows the POS system to send an amount and a reference to the payment terminal and then receives a payment status. This eliminates the need for an employee to re-enter the amount and ensures that the sale is processed correctly.
No. The point-of-sale software, terminal, payment provider, protocol, and versions must be compatible. Use only officially supported combinations. OmEs pay reviews the technical documentation before committing to an integration.
A local connection communicates within the business or directly with the device. A cloud API runs through the provider’s infrastructure and may be suitable for centralized or online applications. Both have their own network, security, and maintenance requirements.
An API key is a credential that allows an application to access an API. It can be linked to permissions, an environment, or a merchant account. An API key alone is not enough; you also need the correct endpoints, error handling, security, and testing.
No. Bancontact is a payment method. Technical credentials are issued by the relevant provider, gateway, or integration platform and are tied to a specific account and environment. Which methods work depends on activation and the contract.
Not in browser code, mobile app bundles, public repositories, email, or regular documents. Store secrets on the server side in a secret manager or secure configuration, restrict access, log usage, and rotate keys in the event of a security risk or personnel change.
The register must receive a valid terminal or provider status or be able to retrieve that status again. A customer who returns to a screen or a printed receipt alone is not sufficient when the network status is uncertain.
The application must not blindly process the payment again. It must identify the original transaction by a unique reference and retrieve its final status. The exact recovery procedure depends on the interface and must be tested in advance.
Some interfaces support full or partial refunds, while others require the use of the provider portal or terminal operations. Limit permissions, use original transaction references, and test how the point-of-sale system and accounting records are updated.
The developer maintains the application code. The provider maintains its API, and OmEs pay supports the agreed-upon terminal and provider configuration. Specify version updates, monitoring, incidents, and testing responsibilities in the contract.
