Bluefin's ShieldConex® Proxy is a secure proxy that provides pass-through tokenization. This approach helps enterprise merchants address the following challenges: the challenge of managing sensitive data internally while interacting with payment processors; the challenge of avoiding processor lock-in; and the challenge of multi-processor interactions. Our proxy handles these challenges, and more, by offering a secure unified API.

The ShieldConex® Proxy is a vaultless secure data exchange API that incorporates the powerful capabilities of ShieldConex® Tokenization and Decryptx® PCI-validated Point-to-Point Encryption (P2PE). You can use it to take your data security to the next level.

Leveraging detokenization, the ShieldConex® Proxy seamlessly relays sensitive data embedded within JSON or XML messages between the Merchant and the Processor. With the ability to extract P2PE Payloads, perform decryption through Decryptx®, re-insert decrypted data into the message, and proxy authorization to the Processor, ShieldConex® ensures a secure and efficient data flow.

Decryptx®, mentioned above, 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 your clients.

Key Benefits

• Reduce and remove PCI compliance overhead by using tokenization across the entire payment process
• Faster time-to-market and lower maintenance costs due to our unified API
• Achieve 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

• Realtime Tokenization and Detokenization:
  • Gateway will automatically tokenize and/or detokenize 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.
• Realtime Point-To-Point Encryption Decryption:
  • The ShieldConex® Proxy excels in real-time decryption of PCI-validated cardholder data through a secure channel to the Processor endpoint.
• Format Preserving Token Generation:
  • Generate format-preserving tokens directly from EMV/P2PE transactions, ensuring compatibility and security.
• Secure Communication:
  • Share sensitive tokenized data seamlessly with Partners and Affiliates, enhancing collaboration while maintaining data security.
• Bluefin Keys in Payment Terminals:
  • Empower merchants with the flexibility to switch between Processors without rekeying terminals, optimizing operational efficiency.
• Secure iframe Integration:
  • A secure iframe facilitates the collection of cardholder data 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:
  • In a new innovation, the ShieldConex® Proxy introduces auto-tokenization capabilities. The Primary Account Number extracted from EMV payloads undergoes tokenization through ShieldConex®. Merchants can harness the generated tokens for secure and efficient handling of Card Not Present transactions.
• Multi-Processor Support:
  • Works with all Payment Processors. Delivers Processor Independence. Tokens will work with any Processor – so no more exporting and importing of tokens when changing Processors.
• P2PE Independence:
  • Utilize any of Bluefin's 125+ P2PE devices which are EMV certified by the Processor. Bluefin covers the P2PE and forwards SALE to Processor. Devices are covered under Bluefin’s P2PE solution, providing an extensive range of device choice with your Processor.
• Data Support:
  • Can be used with all payment processing, PII, or PHI data. Any sensitive messaging data can be processed.
• Multi-Processor Tokens:
  • The same ShieldConex® Proxy-generated token can be used on any Processor, meaning 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 the P2PE ShieldConex® Proxy can be used to qualify for SAQ-P2PE - processing payment without even having clear-text PAN in your environment.
• Multiple Supported Processing Forms:
  • eCommerce, Card Not Present, 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.

Thanks to the ShieldConex® Portal and P2PE Manager, there is complete visibility into transactions and their processing, as well as the Chain-of-Custody, Asset Management, and Device Attestation capabilities through the Manager. On top of this, the ServiceNow App can also be used or P2PE Management.

For further information on the ShieldConex® Tokenization service, view other documentation here.

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. 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. 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 and the response is proxied back to the Client.

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.