Full screen / Iframe Integration

Introduction
Integration for data capture
1. Operation of the data capture (example)
2. Methods of payment according to the integration
Parameters

Introduction

The purpose of using an integration for capturing customer card data is to facilitate compliance with the PCI-DSS standard of the web application. So, the collection of banking data is done in the secure environment of PAYCOMET and then treated in a Server2Server conversation without the risk of data theft.

Integration for data capture

This solution enables the generation of a form of data captura with the look&feel predefined in the product control panel. This solution must be activated by PAYCOMET, so if it does not appear in the control panel, you must request it by opening an administrative ticket (Support → Open ticket → Administrative/Operational).

In this section you will be able to see a preview of the styles applied below. Styles allow reference to external sites but must respond with a digital certificate correctly signed by a trusted entity; otherwise the customer browser will display an error that will generate mistrust in your customer:

The template can be customized from the section: (Terminals->"Terminal name"->Payment form). Here are the fields that can be modified using CSS styles and a preview of said changes.

If the available properties do not meet the needs of the application, you may request a development of specific "Template" by opening an administrative ticket (Support → Open ticket → Administrative/Operational).

We will inform you of the steps to be followed and the rules of said development.

The functionalities available in Bankstore IFRAME are

Function: (add_user)
Function: (execute_purchase)
Function: (create_subscription)
Function: (create_preauthorization)
Function: (execute_purchase_dcc)

Important

Subscriptions do not run on sandbox accounts.

Subscriptions can be scheduled, modified, and removed, but will not run on sandbox accounts.

Said functionalities are those that involve the collection of the bank details of the customer. Subsequently, once the IDUSER and TOKENUSER data have been collected, XML and REST interfaces may be used to execute purchases, modify subscriptions, information of user card data, cancel subscriptions, etc...

Operation of the data capture (example)

The purpose of using an integration to capture customer card data is to facilitate compliance with the PCI-DSS standard of the Web application. In this manner, the collection of bank data is carried out in the PAYCOMET secure environment for processing them later in a Server2Server conversation without risk of the data being susceptible to theft.

In a fictional environment we would find the following scenario:

A business with high recurrence wants to store the bank details of the customer to facilitate future purchases. The techniques for collecting their bank details are two:

From their customer account. In their control panel they can modify their billing and shipping information and even their associated credit/debit card. Thus, at the end of the shopping cart, they will make the order payment with just one click.
In the first purchase. The customer enters all their bank details in the final process of the cart and these will be stored for future purchases. In this way, storage is done in a "transparent" way when completing the order.

In the first case, the customer is authenticated on the e-commerce platform because it is a previously registered user. They login to their Control Panel and chose to add a credit/debit card to their account to make the payments. The business shows in an integrated way in their control panel an form to capture data and PAYCOMET notifies the business of the result. The business stores the IDUSER and TOKENUSER data in the customer's account (they may have several, in order to have multiple cards), to subsequently make payments.

The customer enters the data into on PAYCOMET's form (aesthetically integrated with the web of the business) and PAYCOMET notifies the IDUSER and TOKENUSER data in the case of success, with a delay.

The business stores the data associated with the account of its customer to execute a payment through SOAP XML integration.

In the second case (storage on the first purchase), the customer places an order normally and when selecting the method of payment by credit/debit card, the bank details are requested to proceed to

The bank details are introduced in an capture form generated by PAYCOMET returning both the storage data of the user (IDUSER and TOKENUSER) and the result of the transaction.

This will happen only if the business does not have the two IDUSER and TOKENUSER data. Otherwise the communication would not be done by a capture form.

In the situation where the business has the IDUSER and TOKENUSER data, either by obtaining them through add_user, the customer has entered their data from their control panel of the business, or through execute_purchase, the customer has already made a purchase previously, the method for making a purchase is different. The method to be used shall be by a Server2Server (XML or REST) connection where the business will use the execute_purchase service directly with PAYCOMET.

It is recommended to use some kind of authentication (PIN or similar) to execute the execute_purchase service to prevent unsolicited purchases.

Said unsolicited purchases are usually subject of dispute of the operation and may incur additional charges from the bank and, if it is a repeated offense, the account could be canceled.

BAKSTORE IFRAME Integration

Integration via IFRAME (an independent web page located within another web page, in this case that of the PAYCOMET payment gateway and the store, respectively) is carried out via an IFRAME object with the URL address.

https://api.paycomet.com/gateway/ifr-bankstore

Below is an example of the HTML code (the request parameters have been simplified, which will be covered below):

<iframe title="titulo"  sandbox="allow-top-navigation allow-scripts allow-same-origin allow-forms" src="https://api.paycomet.com/gateway/ifr-bankstore?MERCHANT_MERCHANTCODE=0gs265nc……" width="400" height="525" frameborder="0" marginheight="0" marginwidth="0" scrolling="no" style="border: 0px solid #000000; padding: 0px; margin: 0px"></iframe>

To avoid blocking the redirections required by the payment process in some browsers with security restrictions, it is essential to indicate these parameters in the iframe declaration.

sandbox="allow-top-navigation allow-scripts allow-same-origin allow-forms"

The request parameters must be formatted in the following manner:

PARAM1=VALOR1&PARAM2=VALOR2&PARAM3=VALOR3

Operations allowed:

ID	Operation
107	User registration in the system (`add_user`)
1	Payment (User implicit registration in the system) (`execute_purchase`)
9	Subscription registration (User implicit registration in the system) (`create_subscription`)
109	Charge to an existing user (`execute_purchase_token`)
110	Subscription registration to an existing user (`create_subscription_token`)
114	Subscription registration to an existing user (`execute_purchase_rtoken`)
3	Preauthorization Registration (User implicit registration in the system) (`create_preauthorization`)
6	Preauthorization Confirmation (`preauthorization_confirm`)
4	Preauthorization Cancelation (`preauthorization_cancel`)
111	Preauthorization registration to an existing user (`create_preauthorization_token`)
117	Preauthorization registration to a user by Reference (`create_preauthorization_rtoken`)