Send card details Action

This page describes the “Send card details” action for our Primer Vault app. This app is only available on demand. Speak to your Customer Success Manager or raise a ticket on our Support Portal. If you don’t have access, please contact your account administrator for assistance.

Primer Vault app

Use this app to pass card details to a PCI compliant endpoint using the “Send card details” action. To do so you have to pass in a Primer token, configure the endpoint, and provide a payload with specific placeholders.

Setting up the action

The “Send card details” action currently supports the following inputs:

Input	Type	Description
Primer token	string	The multi use token ID for a user referring to a specific credit card.
Target domain	select	A list of enabled PCI compliant third-parties. This list is empty by default and needs to be enabled for each account manually, pending a PCI review.
Target path	string	The path within the third-party endpoint to post card details to.
Payload	string	Map a field to pass the payload through. Make sure to use the placeholder variables as needed.
Content Type	string	Set the content type of the payload, like `application/json` or `application/xml`
Placeholder variables	-	A set of available token fields that the action will replace with actual values from the token.
Cardholder name	string	The placeholder for the cardholder name, by default `{{CARDHOLDER_NAME}}` but can be changed according to the individual needs.
Card number	string	The placeholder for the cardholder name, by default `{{CARD_NUMBER}}` but can be changed according to the individual needs. Important: Sending a payload that does not at least contain the placeholder for card number will fail the action immediately without attempting a third-party request.
Expiry month	string	The placeholder for the card expiration month, by default `{{EXPIRATION_MONTH}}` but can be changed according to the individual needs.
Expiry year	string	The placeholder for the card expiration year, by default `{{EXPIRATION_YEAR}}` but can be changed according to the individual needs.
Expiry year format	yyyy or yy	Different endpoints handle the expiration year differently, so you can choose which format to send.
Custom headers	list	You can set additional headers to be sent if necessary. You must not use this for API keys or other authorization methods, as the credentials will be visible in the Workflow Run view. Instead, set credentials and authorization header name when configuring the App itself.
Request ID	string	You can specify a request ID that will be returned as an output by this action. This can be useful if you want to forward the response to a different endpoint because you can then use the request ID to easier reconcile the requests.
Fail action on unsuccessful request?	checkbox	By default, this is on and the Workflow Run will fail if we do not get a 2xx response from the PCI compliant endpoint. You can disable this and create branching logic based on response status to build a comprehensive workflow handling different responses. Do note that timeouts will always lead the request to fail as you can’t assume the request was received or not received.

This action can only work with MULTI_USE tokens, as a SINGLE_USE token would be marked as consumed after the first authorize or forward attempt.

Card expiry

Because third-parties handle expiration dates differently, you can send in a custom string with month & year and primer will update the values appropriately based on the format selected. An example to send in card expiry could be:

JSON

	"expiry": "{{EXPIRATION_MONTH}}/{{EXPIRATION_YEAR}}",

CVV data

Keep in mind that the card CVV is only stored for a maximum of 15 minutes. If you need the CVV to be forwarded to a PCI compliant endpoint, you need to create a workflow that is triggered within that time period.

Action outputs

On success, the action will return the following fields as outputs:

Output	Type	Description
Request ID	string	You can specify a request ID as input that will be returned as an output by this action. This can be useful if you want to forward the response to a different endpoint because you can then use the request ID to easier reconcile the requests.
Response body	string	The response we received from the PCI compliant endpoint. You could forward this response back to your own endpoint using the send web request action.
Response content-type	string	The content-type for the response from the PCI compliant endpoint. Usually `application/json` or `application/xml`.
Response status	string	The response status from the PCI compliant endpoint. This is useful if you set the action to not fail the workflow in case the request could not be sent. Do note that timeouts will always lead the request to fail as you can’t assume the request was received or not received.

Use cases

There are different reasons as to why card details from a token need to be shared, such as within the travel industry. To forward card details like card number, cardholder name, and expiry date to a PCI compliant endpoint, you have multiple options within workflows:

Custom flow via web request trigger

The web request received trigger allows you to send in a custom JSON payload to manually start a workflow based on your own logic. We recommend sending in a payload like this:

JSON

{
	"requestID": "YOUR_REQUEST_ID",
	"token": "PRIMER_TOKEN_TO_SHARE",
    "useCase": "SHARE_PARTNER_1",
	"payload": {
        "orderId": "1234",
        "customerId": "5678"
        "cardDetails": {
            "number": "{{CARD_NUMBER}}",
            "cardholder": "{{CARDHOLDER_NAME}}",
            "expiry": "{{EXPIRATION_MONTH}}/{{EXPIRATION_YEAR}}",
            "securityCode": "{{CVV}}"
        }
    }
}

When setting up the action later, these placeholders can be configured, as well as the field for the payload. It is also possible to branch a workflow. If you have different third-parties to share data with, you could use the useCase field to branch to send different payloads to different partners.

As part of a payment flow

If you know that the card details need to be shared as part of a payment journey, you could also set up a dedicated workflow, by using either the payment status updated trigger or the authorize action. If you create a condition on the status , then you could add the “send card details” action of the Primer Vault app. Note that you would need to share the required payload within the metadata of the payment request.

Monitoring requests

Workflow Runs are automatically available for any workflow that was executed. For the “send card details” action the requests/responses will show placeholders instead of the actual card details sent to the endpoint.

​Primer Vault app

​Setting up the action

​Card expiry

​CVV data

​Action outputs

​Use cases

​Custom flow via web request trigger

​As part of a payment flow

​Monitoring requests

Primer Vault app

Setting up the action

Card expiry

CVV data

Action outputs

Use cases

Custom flow via web request trigger

As part of a payment flow

Monitoring requests