📘
See the References page for configuration help, explanations and clarification.

Overview

This section introduces various ORCA configurations showcasing ShieldConex® and Decryptx® actions in practice. These actions are essential to understanding how ShieldConex® and Decryptx® work in combination with ShieldConex® Orchestration, offering maximum security and reducing PCI scope. For more guides, we suggest referring back to the ORCA Configuration Essentials and Introduction.

📘
Note
For simplicity, we use passthrough for proxy.authorization in all of the following examples.

JSONPath and XPath

Before looking at some API examples, it is essential to know how JSONPath and XPath parse data from the payload. ShieldConex® Orchestration supports these, and they are specified with transformationType and transformationPath in the ORCA configuration.

JSONPath is a tool for navigating and extracting data from JSON structures. It provides a concise and flexible syntax to access specific elements within JSON objects.

For example:

{
    "Card": {
        "Track2": "4444333322221111",
        "Password": "supersecret"
    }
}

$.Card.Track2 - where $ is the root object and . the child member operator
$.Card.Password - selects the value of the path - evaluates to "supersecret"

XPath, often used in conjunction with XML, is a query language for selecting nodes from an XML document. It is similar to JSONPath but only used in the context of XML.

For example:

<?xml version="1.0" encoding="UTF-8"?>
<Card>
  <Name>John Smith</Name>
  <Password>supersecret</Password>
  <Track2>4444333322221111</Track2>
</Card>

//Card/Track2/text() - where // is the root of XML document, / the child member operator and text() the text content of the element - evaluates to "4444333322221111"

Below are some libraries that you can use as a tool or to sharpen up your understanding of JSONPath and XPath.

NPM libraries:

Online evaluators:

https://jsonpath.com

XPath Namespaces Usage

Using XML namespaces as part of the ORCA API request requires a different way of selecting the XML body values from a ShieldConex® ORCA configuration. This is due to the fact that XML can have multiple namespaces, resulting in tags conflicts or complications. This is especially the case with XPath 1.0 (which doesn't support easy namespace handling) when there is the default namespace declaration without a prefix.

For example,

<CreditCardSale xmlns="https://transaction.elementexpress.com">
  <Card>
    <CVV>123</CVV>
  </Card>
</CreditCardSale>

ORCA Configuration

For example, if we were to have an ORCA configuration and request configuration such as the following:

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//CreditCardSale/Card/PAN/text()",
          "pattern": "all"
        },
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//CreditCardSale/Card/CVV/text()",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Result/Secret/text()",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "parser",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//CreditCardSale/Card/PAN/text()",
          "format": "pan",
          "dataType": "string",
          "default": "mydefault"
        },
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//CreditCardSale/Card/CVV/text()",
          "format": "cvv",
          "dataType": "string",
          "default": "mydefault"
        }
      ]
    }
  ]
}

Request Configuration

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "Content-Type": "application/xml",
  },
  body: `<?xml version="1.0" encoding="UTF-8"?>
    <CreditCardSale xmlns="https://transaction.elementexpress.com"/>`
}

The transformationPaths, as such, are not going to cut it so we need to change all the transformationPaths from:

"transformationPath": "//CreditCardSale/Card/CVV/text()"

To:

"transformationPath": "/*[name()='CreditCardSale']/*[name()='Card']/*[name()='CVV']/text()"

With the latter, XPath Parser doesn't have any trouble extracting/selecting that certain path from the XML payload in case the same tags come from the multiple namespaces.

If we have the following XML payload,

<CreditCardSale xmlns="https://transaction.elementexpress.com">
  <Card>
    <CVV>123</CVV>
  </Card>
</CreditCardSale>

"transformationPath": "//CreditCardSale/Card/CVV/text()"

The transformationPath will return nothing in XPath 1.0 because those element names belong to a namespace.

To avoid the prefix issue, we can use the combination of the child member operator and the wildcard (selecting any element node - regardless of its name).

"transformationPath": "/*[name()='CreditCardSale']/*[name()='Card']/*[name()='CVV']/text()"

An alternative, and more safe, is to use the namespace prefixes in the case of overriding.

ORCA Configuration

"transformationPath": "/ns:CreditCardSale/ns:Card/ns:CVV/text()"

Request Configuration

<ns:CreditCardSale xmlns="https://transaction.elementexpress.com">
  <ns:Card>
    <ns:CVV>123</ns:CVV>
  </ns:Card>
</ns:CreditCardSale>

For more information, see:

JSON Tokeniztion

ORCA Configuration

Below is the configuration code required by the ShieldConex® Manager to create a new ORCA configuration. See the Quickstart Guide on how to set this up, and the JSON Schema Definitions section for detailed explanations of each property.

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Password",
          "pattern": "all"
        },
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track2",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Result.Secret",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "shieldconex",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "templateRef": "{templateRef}",
      "method": "tokenize",
      "model": "sync",
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track2",
          "fieldName": "scx_token_card_number"
        }
      ]
    }
  ]
}

Request Configuration

Below is the request configuration for your application, along with the POST URL. The {configReferenceID} variable is the reference generated from creating the above ORCA configuration via the ShieldConex® Manager.

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "Content-Type": "application/json",
  },
  body: {
    "Card" : {
      "Name" : "John Smith",
      "Password" : "supersecret",
      "Track2" : "4444333322221111"
    }
  }
}

📘
Note
If we look at our target destination, or the webhook - after the ShieldConex API tokenizes the data, this is the tokenized data that the target destination has accepted. In other words, the instruction applies the substitution of the data by default. According to the References,

instructionType (string) (Optional) (default: "substitution"):

substitution - tokenize or detokenize information and replace the source data in the payload, this is the default setting when the variable is not defined in the configuration

passthrough - tokenize without replacing any data in the payload and retrieve tokens asynchronously using the BFID returned in the response of the ORCA API request
{
  "Card": {
    "Name": "John Smith",
    "Password": "supersecret",
    "Track2": "5850459886792406"
  }
}
In the response headers proxied back to us, we get the scx-tokenize-bfid that is later used for detokenization.

JSON Detokenization

ORCA Configuration

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Password",
          "pattern": "all"
        },
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track2",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Result.Secret",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "shieldconex",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "templateRef": "{templateRef}",
      "method": "detokenize",
      "model": "sync",
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track2",
          "fieldName": "scx_token_card_number"
        }
      ]
    }
  ]
}

Tokenization Request Configuration

In order to run this detokenization example, something must first be tokenized. See the tokenization request configuration below.

POST https://secure{-*}.shieldconex.com/api/tokenization/tokenize

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "Content-Type": "application/json",
  },
  body: {
    "reference": "myref",
    "templateRef": "{templateRef}",
    "values": [
      { "name":"scx_token_card_number", "value":"4444333322221111" }
    ]
  }
}

🚧
Omit Flag
The tokenization API endpoint can also take the omit flag in the query parameters. For example,

POST https://secure{-*}.shieldconex.com/api/tokenization/tokenize?omit=1

The omit flag used in the tokenization API has had 2 options in the past - when set to 0, the tokens are returned in the response to the request, and when set to 1, the tokens would be cached by Bluefin to be retrieved asynchronously. The default value is 0 or false. We have added an additional option to set this value to 2, which will result in the tokens being returned in the response and cached by Bluefin for up to 1 hour.

Detokenization Request Configuration

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "scx-bfid": "{BFID}", // BLUEFIN ID RETURNED BY ABOVE TOKENIZATION CALL
    "Content-Type": "application/json",
  },
  body: {
    "Card" : {
      "Name" : "John Smith",
      "Password" : "supersecret",
      "Track2" : "{TOKENIZED_VALUE_FROM_ABOVE}"
    }
  }
}

📘
Note
If we look at our target destination, or the webhook - after the ShieldConex API detokenizes the data, the target destination accepts the detokenized data. In other words, the instruction applies the substitution of the data by default. According to the References,

instructionType (string) (Optional) (default: "substitution"):

substitution - tokenize or detokenize information and replace the source data in the payload, this is the default setting when the variable is not defined in the configuration

passthrough - tokenize without replacing any data in the payload and retrieve tokens asynchronously using the BFID returned in the response of the ORCA API request
{
  "Card": {
    "Name": "John Smith",
    "Password": "supersecret",
    "Track2": "4444333322221111"
  }
}

JSON Decryptx®

ORCA Configuration

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Password",
          "pattern": "all"
        },
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track2",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Result.Secret",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "parser",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track2",
          "format": "pan",
          "dataType": "string",
          "default": "mydefault"
        }
      ]
    }
  ]
}

Request Configuration

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "dpx-device-serial": "{deviceSerial}",
    "dpx-device-type": "{deviceType}",
    "dpx-payload": "{devicePayload}",
    "Authorization": "{authKey}",
    "Content-Type": "application/json",
  },
  body: {
    "Card" : {
      "Name" : "John Smith",
      "Password" : "supersecret",
      "Track2" : "XXXXXXXXXXXXX"
    }
  }
}

📘
Note
As defined in the ORCA configuration instructions above, Track2 is replaced with the PAN data that Decryptx® extracts and decrypts from the device payload, which is then forwarded to the designated endpoint; that is, the payment processor. The decrypted payload accepted by the target destination looks something like the following:
{
  "Card": {
    "Name": "John Smith",
    "Password": "supersecret",
    "Track2": "4444333322221111"
  }
}
In other words, the instruction applies the substitution of the data by default. According to the References,

instructionType (string) (Optional) (default: "substitution"):

substitution - decrypt information and replace the source data in the payload, this is the default setting when this option is not defined in the configuration

XML Tokenization

ORCA Configuration

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Password/text()",
          "pattern": "all"
        },
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Track2/text()",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Result/Secret/text()",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "shieldconex",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "templateRef": "{templateRef}",
      "method": "tokenize",
      "model": "sync",
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Track2/text()",
          "fieldName": "scx_token_card_number"
        }
      ]
    }
  ]
}

Request Configuration

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "Content-Type": "application/xml",
  },
  body: `<?xml version="1.0" encoding="UTF-8"?>
    <Card>
      <Name>John Smith</Name>
      <Password>supersecret</Password>
      <Track2>4444333322221111</Track2>
    </Card>`
}

📘
Note
After ShieldConex® tokenizes the payload data, the target destination receives the securely tokenized data in the following format. According to the References,

instructionType (string) (Optional) (default: "substitution"):

substitution - tokenize or detokenize information and replace the source data in the payload, this is the default setting when the variable is not defined in the configuration

passthrough - tokenize without replacing any data in the payload and retrieve tokens asynchronously using the BFID returned in the response of the ORCA API request
<Card>
  <Name>John Smith</Name>
  <Password>supersecret</Password>
  <Track2>5850459886792406</Track2>
</Card>
In the response headers proxied back to us, we get the scx-tokenize-bfid that is later used for detokenization.

XML Detokenization

ORCA Configuration

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Password/text()",
          "pattern": "all"
        },
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Track2/text()",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Result/Secret/text()",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "shieldconex",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "templateRef": "{templateRef}",
      "method": "detokenize",
      "model": "sync",
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Track2/text()",
          "fieldName": "scx_token_card_number"
        }
      ]
    }
  ]
}

Tokenization Request Configuration

In order to run this detokenization example, something must first be tokenized. See the tokenization request configuration below.

POST https://secure{-*}.shieldconex.com/api/tokenization/tokenize

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "Content-Type": "application/json",
  },
  body: {
    "reference": "myref",
    "templateRef": "{templateRef}",
    "values": [
      { "name":"scx_token_card_number", "value":"4444333322221111" }
    ]
  }
}

🚧
Omit Flag
The tokenization API endpoint can also take the omit flag in the query parameters. For example,

POST https://secure{-*}.shieldconex.com/api/tokenization/tokenize?omit=1

The omit flag used in the tokenization API has had 2 options in the past - when set to 0, the tokens are returned in the response to the request, and when set to 1, the tokens would be cached by Bluefin to be retrieved asynchronously. The default value is 0 or false. We have added an additional option to set this value to 2, which will result in the tokens being returned in the response and cached by Bluefin for up to 1 hour.

Detokenization Request Configuration

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "scx-bfid": "{BFID}", // BLUEFIN ID RETURNED BY ABOVE TOKENIZATION CALL
    "Content-Type": "application/xml",
  },
  body: `<?xml version="1.0" encoding="UTF-8"?>
    <Card>
      <Name>John Smith</Name>
      <Password>supersecret</Password>
      <Track2> {TOKENIZED_VALUE_FROM_ABOVE} </Track2>
    </Card>`

}

📘
Note
After ShieldConex® extracts and detokenizes the payload data, the target destination receives the detokenized data. According to the References,

instructionType (string) (Optional) (default: "substitution"):

substitution - tokenize or detokenize information and replace the source data in the payload, this is the default setting when the variable is not defined in the configuration

passthrough - tokenize without replacing any data in the payload and retrieve tokens asynchronously using the BFID returned in the response of the ORCA API request
<Card>
  <Name>John Smith</Name>
  <Password>supersecret</Password>
  <Track2>4444333322221111</Track2>
</Card>

XML Decryptx®

ORCA Configuration

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Password/text()",
          "pattern": "all"
        },
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Track2/text()",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Result/Secret/text()",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "parser",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Card/Track2/text()",
          "format": "pan",
          "dataType": "string",
          "default": "mydefault"
        }
      ]
    }
  ]
}

Request Configuration

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "dpx-device-serial": "{deviceSerial}",
    "dpx-device-type": "{deviceType}",
    "dpx-payload": "{devicePayload}",
    "Authorization": "{authKey}",
    "Content-Type": "application/xml",
  },
  body: `
    <?xml version="1.0" encoding="UTF-8"?>
      <Card>
        <Name>John Smith</Name>
        <Password>supersecret</Password>
        <Track2>XXXXXXXXXXXXX</Track2>
      </Card>`
}

📘
Note
As defined in the ORCA configuration instructions above, Track2 is replaced with the PAN data that Decryptx® extracts and decrypts from the device payload, which is then forwarded to the designated endpoint; that is, the payment processor. The decrypted payload accepted by the target destination looks something like the following:
<Card>
  <Name>John Smith</Name>
  <Password>supersecret</Password>
  <Track2>4444333322221111</Track2>
</Card>
In other words, the instruction applies the substitution of the data by default. According to the References,

instructionType (string) (Optional) (default: "substitution"):

substitution - decrypt information and replace the source data in the payload, this is the default setting when this option is not defined in the configuration

XML Decryptx® with Headers

ORCA Configuration

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "header",
          "transformationType": "key",
          "transformationPath": "password",
          "pattern": "all"
        },
        {
          "transformationSource": "header",
          "transformationType": "key",
          "transformationPath": "track2",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "xpath",
          "transformationPath": "//Result/Secret/text()",
          "pattern": "all"
        },
        {
          "transformationSource": "header",
          "transformationType": "key",
          "transformationPath": "password",
          "pattern": "all"
        },
        {
          "transformationSource": "header",
          "transformationType": "key",
          "transformationPath": "track2",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "parser",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "instructions": [
        {
          "transformationSource": "header",
          "transformationType": "key",
          "transformationPath": "track2",
          "format": "pan",
          "dataType": "string",
          "default": "mydefault"
        }
      ]
    }
  ]
}

Request Configuration

Below is the request configuration for your application, along with the POST URL. The {configReferenceID} variable is the reference generated from creating the above configuration via the ShieldConex® Manager. Unlike the other examples, we now pass payload data into headers.

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}

{
  method: "POST",
  headers: {
    "dpx-device-serial": "{deviceSerial}",
    "dpx-device-type": "{deviceType}",
    "dpx-payload": "{devicePayload}",
    "Authorization": "{authKey}",
    "Content-Type": "application/xml",
    "password": "supersecret",
    "track2": "XXXXXXXXXXXXX"
  },
  body: `<?xml version="1.0" encoding="UTF-8"?>`
}

🚧
Note
Unlike the examples above, this time the target destination receives the decrypted data substituted in the request headers.

JSON Tokenization with Queries

ORCA Configuration

Below is the configuration code required by the ShieldConex® Manager when creating a new ORCA configuration. See the Quickstart Guide on how to set this up, and the JSON Schema Definitions section for detailed explanations of each property.

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "passthrough"
    },
    "logSettings": {
      "requestMasks": [
        {
          "transformationSource": "query",
          "transformationType": "key",
          "transformationPath": "password",
          "pattern": "all"
        },
        {
          "transformationSource": "query",
          "transformationType": "key",
          "transformationPath": "track2",
          "pattern": "all"
        }
      ],
      "responseMasks": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Result.Secret",
          "pattern": "all"
        },
        {
          "transformationSource": "query",
          "transformationType": "key",
          "transformationPath": "track2",
          "pattern": "all"
        },
        {
          "transformationSource": "query",
          "transformationType": "key",
          "transformationPath": "password",
          "pattern": "all"
        }
      ]
    }
  },
  "actions": [
    {
      "type": "shieldconex",
      "authorization": {
        "type": "basic",
        "username": "{partnerID}",
        "password": "{partnerKey}"
      },
      "templateRef": "{templateRef}",
      "method": "tokenize",
      "model": "sync",
      "instructions": [
        {
          "transformationSource": "query",
          "transformationType": "key",
          "transformationPath": "track2",
          "fieldName": "scx_token_card_number"
        }
      ]
    }
  ]
}

Request Configuration

POST https://proxy{-*}.shieldconex.com/api/v1/partners/{partnerID}/configurations/{configReferenceID}?password=supersecret&track2=4444333322221111

{
  method: "POST",
  headers: {
    "Authorization": "{authKey}",
    "Content-Type": "application/json",
  },
  body: `{ "reference": "myref" }`
}

🚧
Note
Unlike the examples above, this time the target destination receives the tokenized data substituted in the request query.

📘See the References page for configuration help, explanations and clarification.

Overview

📘Note

JSONPath and XPath

XPath Namespaces Usage

ORCA Configuration

Request Configuration

ORCA Configuration

Request Configuration

JSON Tokeniztion

ORCA Configuration

Request Configuration

📘Note

JSON Detokenization

ORCA Configuration

Tokenization Request Configuration

🚧Omit Flag

Detokenization Request Configuration

📘Note

JSON Decryptx®

ORCA Configuration

Request Configuration

📘Note

XML Tokenization

ORCA Configuration

Request Configuration

📘Note

XML Detokenization

ORCA Configuration

Tokenization Request Configuration

🚧Omit Flag

Detokenization Request Configuration

📘Note

XML Decryptx®

ORCA Configuration

Request Configuration

📘Note

XML Decryptx® with Headers

ORCA Configuration

Request Configuration

🚧Note

JSON Tokenization with Queries

ORCA Configuration

Request Configuration

🚧Note

📘
See the References page for configuration help, explanations and clarification.

📘
Note

📘
Note

🚧
Omit Flag

📘
Note

📘
Note

📘
Note

🚧
Omit Flag

📘
Note

📘
Note

🚧
Note

🚧
Note