ShieldConex Proxy - Intro - Orchestration

Overview

Bluefin's ShieldConex® Proxy enables you to take your data security to the next level.

ShieldConex® Proxy is a vaultless secure data exchange API that provides and incorporates the powerful capabilities of ShieldConex® Tokenization (pass-through tokenization) and Decryptx® PCI-validated Point-to-Point Encryption (P2PE). It is a flexible yet powerful security proxy.

Through its secure unified API, it enables enterprise merchants to solve challenges like the following:

• Manage sensitive data internally while interacting with payment processors
• Avoid processor lock-in
• Multi-processor interactions

ShieldConex® Proxy leverages detokenization to seamlessly relay sensitive data embedded in JSON or XML messages between the merchant and the processor. It ensures secure and efficient data flow and next-level orchestration through its ability to extract P2PE payloads, perform decryption through Decryptx®, re-insert decrypted data into the message, and implement proxy authorization to the processor.

Orchestration

Other orchestration offerings on the market provide a common API interface and then transform and translate the input data to the destination format. This approach requires these solutions to perform an integration and certification to each of these destinations, which is resource-intensive and costly for the providers. It is also limiting as they need to code to the lowest common denominator; unique API fields and elements are generally not supported.

ShieldConex® Proxy provides a more powerful solution. It relies on the client integrating and certifying with the endpoint provider. This could be an EMV integration with a payment processor or a card not present (CNP) level 3 (L-III) integration that transmits a lot of data to the payment processor. ShieldConex® Proxy handles only the specific fields that require actioning, leaving all other data untouched.

In the case of an EMV transaction, Bluefin applies its P2PE service to encrypt the cardholder data in the payment terminal and decrypt it on the fly using the ShieldConex® Proxy in combination with Bluefin's Decryptx® solution. The decrypted data is then inserted into the message and sent securely over TLS to the payment processor for authorization. The response from the processor is proxied back to the client.

For CNP use (ecommerce or MO/TO), a ShieldConex® token is detokenized by ShieldConex®, and the cardholder data is reinserted into the message and sent to the processor for approval. The response from the processor is proxied back to the client.

The most powerful aspect of the ShieldConex® proxy is that it can be used with any endpoint over the Internet (see below). The solution can be used for payments, in healthcare, and with PII and PHI data.

Once the ShieldConex® Proxy is configured to support the client's application, it can be used immediately. ShieldConex® Proxy functions like an extension of the client's environment.

Integration to endpoints

As mentioned above, the ShieldConex® Proxy leverages the integration work already performed by the client.

For example, if the client has an appliance on their local network for decrypting or detokenizing data before sending it to the processor, this would be invisible to the processor; it would simply be a normal part of good security practice. The difference with the ShieldConex® Proxy is that the decryption or detokenization of data takes place in Bluefin's PCI DSS environment. The client no longer has sensitive data (PCI/PII/PHI) in their environment, which results in massive PCI scope reduction.

Decryptx®

Decryptx® is a sophisticated and secure data decryption solution designed to streamline the decryption process while ensuring maximum data security. This enables processors, payment gateways, and software platforms to universally connect to Bluefin and offer our PCI-validated P2PE solution directly to their clients.

Key benefits of ShieldConex® proxy

• Reduce and remove PCI compliance overhead using tokenization across the entire payment process.
• Faster time-to-market and lower maintenance costs with our unified API.
• Full payment processor flexibility to mix and match processors as needed.
• Unified and universal tokens that work in all use cases.
• Increased scalability and reliability options for your system architecture.

Key Features of ShieldConex® Proxy

• Real-time tokenization and detokenization:
  • The gateway automatically tokenizes and detokenizes discrete elements in the payload.
  • ShieldConex® Proxy offers on-the-fly tokenization and detokenization, providing a swift and secure process for data transmission to endpoints.
• Real-time point-to-point encryption and decryption:
  • ShieldConex® Proxy excels in real-time decryption of PCI-validated cardholder data through a secure channel to the processor endpoint.
• Format-preserving token generation:
  • ShieldConex® Proxy generates format-preserving tokens directly from EMV/P2PE transactions, ensuring compatibility and security.
• Secure communication:
  • Shares sensitive tokenized data seamlessly with partners and affiliates, enhancing collaboration while maintaining data security.
• Bluefin keys in payment terminals:
  • Gives merchants the flexibility to switch between processors without rekeying terminals, optimizing operational efficiency.
• Secure iframe integration:
  • A secure iframe means that cardholder data can be easily collected from the merchant's website. Bluefin returns tokens, allowing them to be used for payments via any processor through the ShieldConex® Proxy.
• Auto-tokenization of EMV-derived PAN:
  • ShieldConex® Proxy introduces a new innovation: auto-tokenization capabilities. It tokenizes the primary account number (PAN) extracted from EMV payloads. Merchants can then harness the generated tokens for secure and efficient handling of CNP transactions.
• Multi-processor support:
  • ShieldConex® Proxy works with all payment processors, thus delivering processor independence. Tokens work with any processor – no more exporting and importing tokens when changing processors.
• P2PE Independence:
  • Utilize any of Bluefin's more than 125 P2PE devices that are EMV-certified by the processor. Bluefin covers the P2PE and forwards SALE to the processor.
• Data support:
  • ShieldConex® Proxy can be used with all payment processing, PII, or PHI data, and can handle any sensitive messaging data.
• Multi-processor tokens:
  • The same ShieldConex® Proxy-generated token can be used on any processor, meaning that you own your own tokens, and don't need to convert tokens if you change processor.
• Reduce e-tailer PCI scope:
  • The iframe ShieldConex® Proxy can be used to reduce PCI scope to a SAQ-A and to qualify for SAQ-P2PE - processing payment without the need for clear-text PAN in your environment.
• Multiple supported processing forms:
  • ecommerce, CNP and EMV/P2PE processing are all supported.

These features collectively establish the ShieldConex® Proxy as a comprehensive solution, offering real-time security, flexibility, and collaboration capabilities in managing payment data between merchants and processors.

Conclusion

Thanks to the ShieldConex® Portal and P2PE Manager, you enjoy complete visibility into transactions and how they are processed, as well as chain-of-custody, asset management, and device attestation capabilities. On top of this, the ServiceNow app or P2PE management can also be used.

See this documentation [here] (https://developers.bluefin.com/shieldconex/docs/shieldconex-overview) for further information on the ShieldConex® tokenization service,

Explore the Decryptx® Parser here.

Use Cases

iframe-Based Secure Tokenization/Detokenization Processing

By using our embedded iframe approach to protect user interactions, you can avoid PCI and other compliance issues by working only with Bluefin tokens. Sensitive payment data, PII, and PHI can be captured within the iframe, avoiding the need to handle this data in your systems. Instead, our iframe solution immediately tokenizes the sensitive data. All tokens are made available in one Bluefin API call, and can be used as is for proxied Processor API interactions.

Sensitive data is collected safely using the ShieldConex® iframe. The client retrieves tokenized data, and by making use of the ShieldConex® proxy, the tokens - along with additional payload elements - are sent for detokenization. This secure processing mode ensures that the client never directly handles sensitive data.

Check out the Example Use Cases page for an in-depth look at the iframe-Based Secure Tokenization/Detokenization Processing use case (sample source code included).

• (1&2) Consumer opens up Client Website and ShieldConex® iframe elements are loaded into the Consumer’s Browser.
• (3) As Consumer enters data into the iframe elements, they are captured directly by ShieldConex® and tokenized. A BFID (Bluefin ID) is returned.
• (4) Tokens are cached in ShieldConex® for a Maximum of 1 hour.
• (5) All data needed to complete the transaction is sent to the Clients processing service, including the BFID.
• (6&7) Using the BFID, the Client requests their tokens and they are returned.
• (8) The Client sends the message to ShieldConex® in the format required by their processor with the tokens in place rather than PAN (credit card). The ShieldConex® Proxy will detokenize the tokens, reinsert the actual PAN data into the payload, and relay the payment request to the processor.
• (9) The response is proxied back to the Client.

API-Based Tokenization and Detokenization Processing

The tokenization proxy approach allows you to fully replace all sensitive data in your system with our tokens. Because the proxy provides transparent detokenization, this means that no changes to existing business logic are needed, and the tokens can be used as in-place substitutes. Our API allows you to perform a staged migration to tokens without disrupting your system integrations.

This method outlines the straightforward integration of tokenization and detokenization into your API workflow using ShieldConex®'s services. By utilizing this service, your application gains enhanced security without the complexity of manually managing sensitive data. ShieldConex® ensures robust security measures, including PCI compliance and data protection, through Bluefin, alleviating security concerns for your app.

• (1) Client tokenizes all cards on file by pulling them from their database, calling the ShieldConex® tokenization service API’s, and reinserting the tokens in their database. This “devalues” the sensitive data stored. The token and a BFID are returned for storage.
• (2) During the billing cycle, the Client retrieves the ShieldConex® token and BFID from storage and sends it to the ShieldConex® proxy in the format required by their processor with the tokens in place rather than PAN (credit card). The ShieldConex® Proxy will detokenize the tokens, reinsert the actual PAN data into the payload, and relay the payment request to the processor.
• (3) The response is proxied back to the Client.

This example is for recurring calls, but will also work for any OnDemand tokenization or detokenization needs.

EMV/P2PE Processing

Our proxy also handles encrypted cardholder information (e.g PAN) from third party sources such as payment terminals. Using our Decryptx® service, you can perform the same proxying action as with the tokenization use cases. Once again, you are freed from PCI compliance costs because you can send encrypted data via the proxy, which we then decrypt for you in real time and send on the Processor. At no stage does decrypted data enter your systems.

Decryptx® P2PE employs advanced encryption methods like SRED to secure cardholder data at the point of sale. By integrating ShieldConex® Proxy, Decryptx® efficiently decrypts P2PE payloads according to Processor specifications, facilitating seamless authorization processing. This robust combination ensures PCI compliance and safeguards sensitive information throughout the payment processing journey.

• (1) PAN data is encrypted inside the Point of Sale device using SRED. The payload is forwarded to a corporate switch or controller for formatting.
• (2) The P2PE payload is sent to the ShieldConex® Proxy in the format required by the Processor’s specification for authorization.
• (3) The Proxy finds the data elements in the message to properly decrypt the payload. The data is extracted and sent via the Decryptx® Parser to Decryptx®. The decrypted elements are returned to the Proxy and inserted in the message. (P2PE is complete at this point).
• (4) The message is forwarded to the processor for authorization.
• (5) The response is proxied back to the Client.

EMV Transaction Orchestration Use Case

As described in the Orchestration Introduction above, ShieldConex® Proxy relies on the client integrating and certifying with the endpoint provider. This could be an EMV integration with a payment processor or a card not present (CNP) level 3 (L-III) integration that transmits a lot of data to the payment processor. ShieldConex® Proxy handles only the specific fields that require actioning, leaving all other data untouched. For example, if we had the transaction amount, currency, and transaction identifier that we needed to leave untouched for other transaction processing - ShieldConex® Proxy would ignore them but they still would be present in the payload. Of course, we can choose to mask this data in our proxy configuration for additional security purposes.

• (1) The Client inputs EMV transaction details into the payment terminal. Bluefin applies P2PE service to encrypt the cardholder data in the payment terminal using SRED
• (2) The ShieldConex® Proxy will extract the P2PE payload and decrypt it on the fly in combination with Bluefin's Decryptx® solution
• (3) The decrypted data is then inserted into the message and sent securely over TLS Protocol to the payment processor for authorization
• (4) The response from the processor is proxied back to the client. For example, whether the transaction has failed or succeeded.

Fraud Services

All the same benefits that apply to Payment Processors also apply to third party fraud services. Because you can now use the proxy to access fraud services, and use tokenization to insulate yourself from sensitive data, you gain the same flexibility that you do with Payment Processors: reduced or eliminated PCI/PII/PHI compliance, no service lock-in, more robust scalability and failover, along with many others.

Previously: Transaction data is sent to Payment Provider. Payment Provider makes API call to fraud service. Approves/declines based on fraud score.

With ShieldConex® Proxy: An API call is made to a fraud provider via the ShieldConex® proxy using ShieldConex® tokenized data.

Benefits:

• Direct fraud integration without handling CHD/SAD in your environment.
• Flexibility around:
  • Fraud providers
  • Fraud provider schemas
  • Handling fraud scores
    • Pause transactions
    • Combine fraud score with other data before making decisions

Support

A glossary is available for this document for any acronyms you may need explained.

Looking for Customer or Technical Support? Click here to contact our support team with questions about billing, devices, gateway issues, PCI inquiries, or other current customer-related questions.