Integration Methods
To process transactions with Fabrick Payment Orchestra, the first step is to choose the integration type best suited to your context, from the Fabrick payment page to direct integration through the API.
The integrations differ in two respects: who presents the payment interface to the buyer, Fabrick or the merchant, and where the card data passes through. These two aspects determine the level of customisation available, the development effort and the PCI DSS compliance requirements for the merchant.
- Checkout PageIntegrate the Checkout Page, the Fabrick hosted payment page: the buyer chooses the payment method on a page managed by Fabrick, with direct redirect to card or APM and outcome URLs configurable for each transaction.
- Pay By LinkRequest a payment through a link, QR Code or email with Pay By Link: delivery channels, validity period of the request, direct redirect to card or APM and outcome notification.
- Web ComponentsEmbed the payment in your checkout page with Fabrick Web Components: cards, wallets and alternative payment methods as native HTML elements, with no iFrames or pop-ups.
- LightboxShow the Fabrick payment page in a pop-up over the checkout, with no redirect: loading the script, opening the Lightbox, handling the outcome with a callback and checking the result.
- API OnlyIntegrate the Fabrick Payment Orchestra services directly through the API, without Fabrick payment pages: card form on the merchant's website, wallets, alternative payment methods and token payments.
- PluginFabrick Payment Orchestra integrates with the main e-commerce CMS platforms through official plugins and with third-party solutions — PMS for hospitality and vertical CMS — to simplify online payment acceptance in any business context.
Integration comparison
| Integration | Payment presentation | Card data entry | Card data on the merchant's servers | SAQ |
|---|---|---|---|---|
| Checkout Page | Redirect to the Fabrick page | Fabrick page | No | A |
| Pay By Link | Link, QR Code or email to the Fabrick page | Fabrick page | No | A |
| Lightbox | Pop-up on the merchant's page | Fabrick page in an overlay | No | A |
| Web Component | Component in the merchant's page | Fabrick component | No | A |
| API Only (client) | Merchant's page | Sent directly from the front end to Fabrick | No | A-EP |
| API Only (server) | Merchant's page | Sent from the merchant's server to Fabrick | Yes | D or ROC |
| Plugin | CMS extension | Depends on the plugin mode | Depends on the plugin mode | A or A-EP |
The SAQ type shown is the one typical of each integration. The type to complete must always be confirmed with your acquirer, based on the actual configuration of your website and payment flows.
Hosted integrations
In hosted integrations the payment interface, the authentication flows and the redirects to alternative payment methods (APMs) are handled by Fabrick. The merchant initialises the transaction with the payment/create call and presents the Fabrick page or component to the buyer.
Checkout Page
The buyer is redirected to the Fabrick payment page, which can be customised with the merchant's logo, and chooses one of the enabled payment methods, for example cards and PayPal. A direct redirect to the card details page or to a specific APM is also possible.
It is the quickest solution to integrate, with minimal impact on the merchant's systems.
PCI DSS questionnaire: SAQ A · Go to the Checkout Page guide
Pay By Link
Presents the Fabrick payment page through a link, with the option of setting the validity period of the request. The payment can be offered to the buyer through different channels:
- payment link, to be used for a redirect or shared
- email sent to the buyer by Fabrick's services
- QR Code shown to the buyer for payment by scanning
Since the payment request can be sent outside the checkout, Pay By Link also suits assisted sales, payment reminders and cross-selling and up-selling campaigns.
PCI DSS questionnaire: SAQ A · Go to the Pay By Link guide
Lightbox
Presents the Fabrick payment page in a pop-up displayed over the merchant's website, through a JavaScript library, without the buyer leaving the checkout page.
PCI DSS questionnaire: SAQ A · Go to the Lightbox guide
Web Component
Embeds the payment directly in the merchant's checkout page through native HTML components, configurable through attributes, with no iFrames or pop-ups. The component handles the entire flow, including 3DS authentication and the redirects to APMs.
PCI DSS questionnaire: SAQ A · Go to the Web Component guide
Direct integration
API Only
The API Only integration lets you use the gateway services directly through the API, without the Fabrick payment pages. It suits larger organisations, for example to connect the payment platform to back-office systems, and allows you to build a custom payment page, consistent with the design and user experience of your e-commerce.
The PCI DSS questionnaire depends on where the card data passes through:
| Scenario | Card data flow | PCI DSS validation |
|---|---|---|
| API Only (client) | The data is entered in the browser, app or WebView and sent directly to Fabrick, for example with payment/submit from the front end, without passing through the merchant's servers | SAQ A-EP |
| API Only (server) | The data passes through the merchant's back-end systems before being sent to Fabrick | SAQ D with its AOC or, for merchants at the highest level, ROC and AOC prepared by a QSA |
Plugin
Fabrick provides plugins for the main CMSs and e-commerce platforms, which simplify the connection between the online shop and the gateway with no dedicated development.
PCI DSS questionnaire: depends on the plugin, generally SAQ A or SAQ A-EP · Go to the plugins
PCI DSS requirements: SAQ, AOC and ROC
To understand the responsibilities associated with each integration type, you need to know the PCI DSS compliance requirements, the international standard governing the handling, transmission and storage of payment card data.
SAQ – Self-Assessment Questionnaire
The SAQ is the official questionnaire with which the merchant self-certifies their PCI DSS compliance. The type to complete depends on the integration chosen:
| Type | When it applies | Effort required |
|---|---|---|
| SAQ A | The merchant does not receive, transmit or store card data: the elements of the payment page are provided by Fabrick. This covers integrations with a redirect to the Fabrick page and those that embed the Fabrick page or fields in the merchant's website | The lowest |
| SAQ A-EP | The merchant does not receive card data on their servers, but their web page handles the collection of the data and its direct submission to Fabrick, and can therefore affect the security of the transaction | Broader than SAQ A |
| SAQ D | Card data passes through or is processed on the merchant's servers | The highest, in terms of technical, organisational and security requirements |
AOC – Attestation of Compliance
The AOC is the formal declaration of PCI DSS compliance and always accompanies the validation. When compliance is validated with an SAQ, the AOC is completed by the merchant together with the questionnaire. When it is validated with a ROC, the AOC summarises its outcome and is also signed by the QSA who carried out the assessment.
ROC – Report on Compliance
The ROC is the detailed report prepared by a Qualified Security Assessor (QSA) at the end of the PCI DSS compliance assessment. It is required for merchants at the highest level, identified by the card schemes based on their annual number of transactions; other merchants validate their compliance with an SAQ, unless their acquirer requires otherwise.