Introduction
Microform can be described as a combination of two things:
- A javascript library, let's call it microform.js
- A Cybersource-hosted payment page, or pages, designed to look like a text input field, let's call it a Microform page or just Microform
Microform page would be embedded into merchant's hosted payment page to where normally the input field would be, thus essentially replacing it.
Here's an example of how would an html of a very simple (too simple, actually, it's just for explanation purpose) payment page form look like without a product like Microform.
Now, here's what a page with Microform would like like, before Microform page is loaded:
And after:
This iframe will contain the Microform page, hosted by Cybersource, and the only part of this page which is visible to the user is a text input.
Features
SAQ-A
As Microform is a page hosted externally from merchant's system, it should allow qualification for an SAQ-A PCI DSS assessment.
Visual style
Before Microform is loaded merchant can specify the visual style of Microform page to match the style of the surrounding website. This is achieved through managed classes and css properties.
Managed classes
Microform automatically applies some classes to its container in response to internal state changes. By making use of these classes merchant can style the container.
For example, Microform will assign style flex-microform-invalid to the container if the card number or card security code is not valid. See more about managed classes in the guide.
CSS properties
Through microform.js merchant can style the input text within the iframe element. This is done through CSS properties, please see the guide for the full list and here's an example of how styles are specified:
Microform doesn't support custom fonts.
Events
In addition to styles merchant can subscribe to Microform events through microform.js. Events allow merchant react to changes within Microform and dynamically update the page. For example, an autocomplete event will let merchant know the field was prepulated by browser 'saved card' functionality. A change event will inform of a change to the input field (e.g. text change) and carry additional insight about the card number, see below:
Example of subscribing for a change event:
For a complete list of supported events please check the guide.
In summary, managed classes, CSS properties, and events allow merchant to design Microform to look and feel like the rest of the site.
Encryption and security
Microform offers RsaOaep256 (or just RsaOaep for older browsers) encryption of Cardholder Data (PAN) and Sensitive Authentication Data (CAV2/CVC2/CVV2/CID). Before the card number and card security code leave front-end application they will be encrypted and sent within a JWE.
JWE stands for JSON Web Encryption. Simply put, JWE is an encrypted JWT. See more at https://tools.ietf.org/html/rfc7516.
Microform will only allow itself to be embedded within a trusted website. This is done through Capture Context (trusted endpoints), which will 'start' Microform.
Microform is served over TLS 1.2+ from flex.cybersource.com. This domain is rated A+ by the independent SSL Labs.
In summary, Microform offers Message Layer and Transport Layer Encryption.
Flex API and Transient Tokens
Back-end API Microform talks to is Flex API (a RESTful API). There are two merchant facing endpoints. One is for generation of the Capture Contexts, the other one is for generation of the Transient Tokens.
Transient Token
Transient Token, roughly speaking, is a temporary token which is stored in memory instead of a database. It will be available for just 15 minutes or until the first successful authorization. It is possible to first use it, for example, in a Payer Authentication or a DM transaction, and then for the Authorization.
The key benefit of transient tokens is to have a reference to Sensitive Authentication Data and to be able to pass that reference through back-end systems instead of sending the Card Security Code for example.
Tokenization
Obviosuly, Microform is a type of a payment page. The interesting fact about Microform though is that it does not actually process the payment, instead its purpose is to securely and quickly capture and tokenize any sensitive data and remove it from the front-end application.
The response of Microform (or, to be specific, of Flex API) is the Transient Token, which merchant would through a back-end application send to Cybersource APIs.
Request
Here's a small code fragment showing how tokenisation is done:
For a complete sample of front-end code, please see the guide, Basic Integration paragraph.
Response
Transient Token is a signed JWT.
Header:
Payload:
The jti claim is the Transient Token itself. Depending on API merchant will be required to send just the jti claim or the complete encoded JWT. See respective API guides for more information. It will expire as specified in exp claim.
Sequence diagram
JWT has to be verified before use. Public key to verify Transient Token JWT's signature is provided in the Capture Context flx.jwk claim.