<details> <summary>Adding the Processor</summary> This request submits the processor details for a specific merchant. </details> <details> <summary>Add Value-Added Services</summary> Value-added services (like Customer Vault) are added the same way as card/check processors, but they are far simpler requests.

Each VAS should be added in its own request, so if you wanted to make Customer Vault active, Invoicing active, and Mobile Payments offered, that would be 3 API requests to the /api/v4/processors endpoint.

Service ID Table

serviceId will vary based on which service you’re trying to add. These are based on which services are available in your estate.

Additional Processor Details

A few services allow additional information to configure correctly. These are passed in the processorFields object.

<br>Automatic Card Updater<br> This is optional, but passing the processorFields object will let you configure ACU to run the first day after the service is activated. You can skip the whole processorFields object if you don’t want it to run immediately.

{
    "condition": "offered",
    "status": "active",
    "serviceId": "acu",
    "processorFields": {
        "14": "run_immediately"
    },
    "merchantId": "{{gateway_id}}"
}

<br>CardinalCommerce Centinel 3-D Secure 2.0<br> Query the service using /api/v4/services/centinl2/config for the service for the details of the required fields.

<br>Payer Authentication 2.0<br> Query the service using /api/v4/services/threeds2/config for the service for the details of the required fields.

Request to Make Service Active

All fields are required, and it’s the status variable that’s telling this to be active right away. The serviceId value can be acquired using the /api/v4/services/search documented here.

As seen in the response, value-added services are technically “processors” so they return many values that you also see when adding a credit card processor, but most of this is not useful info for VAS. Important values here include:

• id is the unique identifier for this instance of the service
• serviceId is the code name for the service
• status will show “pending” until the merchant agrees to the fees/TOS, then it will be “active”
• condition will always be “offered” even after the merchant signs up

Request to Make Service Offered

The only real difference is that in the response the status is now “inactive”.

</details> <details> <summary>Cash Processor Overview</summary> The “cash processor” provides the same basic functionality as a credit card or check processor, but simply documents transactions instead of “authorizing” them though a payment processor. This means that requests directed to the “cash processor” don’t require any bank account or credit card information.

Cash processors have several simplifications compared to credit card and electronic check processors when they are configured. Cash processors:

• Do not support duplicate checking.
• Do not support monthly or per-transaction limits.
• Do not support any “processor information” fields or merchant category codes.

For the merchant, the cash processor has certain interface differences from other processors:

• Only sale, refund and credit transactions are available on cash processors.
• Cash transactions can not be saved to the Customer Vault since there is no sensitive information in the transaction information.
• Recurring does not support cash as a payment method for subscriptions.
• Invoicing only supports cash payments when manually charging an invoice in the merchant control panel. Customers will not be able to select cash when paying through the payment link they are emailed.

</details>