Skip to main content
Vindicia Knowledge Center

CashBox Release Notes 13.0.0

CashBox Release Notes 13.0.0

Features and Enhancements

This release includes the following new features and enhancements.

Enhanced Refunds to present Status in API and Reports

Previously, the status of a particular refund didn’t show up in the API. The status was only indicated in the CashBox Portal and the Transaction Refund Detail report.

With this enhancement, a new Data Member, status, has been added to the SOAP Refund object with the possible values: Reported, Processing, Failed, Complete. This addition allows callers of the Refund API methods (version 13.0+) to determine current Refund status.

The Transaction Refund Detail report has been updated to present a matching Status value (Reported, Processing, Failed, or Complete.)

Ticket: CB-4448

Support for Line-Item Refunds (Transaction Item-Level Refunds)

Previously, CashBox supported the notion of a refund against a Transaction as a whole—refunding up to the total of the original transaction.

With this enhancement, merchants using the Refund.perform() API method may continue this practice but may also now specify refunds against individual line items (Transaction Items) individually. Merchants will have the option to designate a refundDistributionStrategy for each refund request, which specifies how CashBox should apply the refund—currently supported values include:

  • None (applies refund using the older Transaction-level approach)
  • SpecifiedItems (allows merchants to designate a refund for any or all of the individual purchase items on the original transactions)
  • When applying a refund to an item, merchants will either specify TaxOnly to refund only the taxes for the item or a specific amount (must not exceed the original TransactionItem amount minus discount(s), minus the sum of all prior refunds against this item) to affect a full or partial refund at the item-level.
  • RemainingBalance (Instructs CashBox to automatically determine the refund amount to cover the complete as-yet-unrefunded balance on all transaction items present on the original transaction.)

Once a particular Transaction has been partially refunded at the Transaction level (older approach), any subsequent refund requests must continue to use the Transaction-level approach.

Ticket: CB-14320

Expand Tax Engine to Report Full and Partial Refunds Using Refund.perform() to Avalara

Refunds issued against transactions using the API Refund.perform() method will now reflect the refunded amounts and tax impacts into the Avalara tax service. Previously, only refunds due to AutoBill.modify() were presented for adjustment to that tax service—this enhancement corrects the gap whereby direct refunds were not sent to the tax service and required manual adjustment.

Ticket: CB-19733

Improved Support Monitoring for CashBox Portal Reports

Internal alert monitoring has been improved to ensure Vindicia Support is automatically notified of stuck or excessively long-running reports.

Ticket: CB-17867

Improved Default Retention Strategy Rules

Vindicia’s proprietary Retention Logic has been updated to simplify merchant set up by defaulting the most common and best practice Retention Strategies that previously had to be individually configured. This does not prevent Support or Deployment Consultants from applying custom logic using Decision Rules.

A separate notice will be sent to all impacted merchants explaining these new defaults further and offering an opt-out if desired.

Ticket: CB-18073

Support Recurring Payments Using PayPal for GlobalCollect Hosted Merchant Link

In addition to supporting PayPal directly as a payment option using Express Checkout, CashBox supports the option via certain Hosted Pages options.

CashBox now supports recurring billing for PayPal through GlobalConnect’s Hosted Merchant Link (HML). Previously CashBox only supported Hosted Merchant Link users applying PayPal as a one-time payment method. While it is generally a best practice to use PayPal Express Check-Out directly through CashBox, when it is needed to process using GlobalCollect, now both one-time and recurring payments will be supported.

Ticket: CB-19670

Sparse Response Description (SRD)

Soap version 13.0 adds a new element to all methods: the Sparse Response Description (SRD). This parameter enables the calling system to constrain the method call to return only specified components. This simplifies the returned content, and it greatly improves the response time within the Vindicia platform by reducing the processing needed for the call.

The SRD is present on all methods, but the ability to specify a sparse return is currently implemented only for the Transaction class (Transaction and TransactionItem data types). Other classes will be added in the near future, as they are implemented, so that merchants can realize the greater speed and reduced processing overhead of SRD without the need to upgrade beyond version 13.0.

Using the SRD:

  • A null SRD element will return the complete response (providing pre-13.0 behavior).
  • The descriptor is a SOAP string, which must be a JSON object describing the expected return. The specified elements should be the desired elements expected in the return.
  • If you ask for a sparse return on a field or object that hasn't been enabled for sparse response, you'll currently get the normal full return for that item.
  • Some fields are required, either practically (for example the VID and merchant identifiers) or in the WSDL. Those will be returned regardless of the SRD.

SRD Example:

Within the Transaction.fetchByAccount() method, where transactions is the name of the returned data element, an SRD might look like this: 

'{"transactions": [

"VID", "merchantTransactionId", "amount", "currency", "timestamp",

{"transactionItems": ["sku", "name","price","quantity", "taxType"]},



With this SRD, you expect that any transaction objects in your return will be sparsely populated, with just VID, merchantTransactionId, and so on. It will also have its statusLog and one sparsely populated sub-object, transactionItems, which will be limited to sku, price, quantity, and taxType.

Ticket: CB-19878

Pagination Added to Transaction.fetchByAccount() Method

The Transaction.fetchByAccount() SOAP API method has also been modified to support paging. This works in a manner similar to the paging in fetchDeltaSince. Transactions are returned in reverse chronological order, so the first page (page 0) has the most recent transactions. For accounts with a large number of transactions, using pagination can speed up response time significantly.

Pagination can be used in combination with the sparse response description (srd), now supported for the Transaction class, which can further improve API performance speed.

Ticket: CB-19878

Support Configurable Avalara Tax Endpoints for Non-Production CashBox Environments

Previously, merchants using the Avalara tax service, either with a direct AvaTax account or using Vindicia's white-label solution, were limited to accessing only the Avalara test/sandbox in Staging and Prodtest -- and only the Avalara Production system from CashBox Production.

This enhancement brings the ability to have Vindicia Support configure your Staging or Prodtest CashBox instances to use Avalara Production. This should ONLY be requested if you have coordinated with Avalara for a "test company" set up in production and if you are able to provide that test company's credentials to Vindicia Support as part of the request. This will prevent sending test transactions to your actual Production tax account at Avalara. This option will support those merchants who choose to use their Production calculation counts and associated fees for any testing, rather than having a dedicated test/sandbox in Avalara.

Ticket: CB-20077

Support Merchant Data (Name-Value Pairs) for Refund Object

The Refund object now supports Merchant Data (unlimited custom fields using name-value pairs) via the CashBox SOAP API (version 13.0 and greater.) 

Note This enhancement is only available via the API. Portal enhancement to allow manual creation and editing of the Merchant Data for these objects is forthcoming in Fall 2015.

Updates have been made to:

  • Refund.perform()

Ticket: CB-20137

Support Merchant Data (Name-Value Pairs) for TransactionItem Object

The TransactionItem object now supports Merchant Data (unlimited custom fields using name-value pairs) via the CashBox SOAP API (version 13.0 and greater.)

Merchant Data defined for a particular AutoBill Item will be inherited by the TransactionItem corresponding to that item for transactions generated as a result of that AutoBill (based on the data defined at the time the transaction is generated.) However, Merchant Data can be defined directly when creating a new transaction using Transaction.auth()/Transaction.capture() or Transaction.authCapture().

Note This enhancement is only available via the API. Portal enhancement to allow manual creation and editing of the Merchant Data for these objects is forthcoming in Fall 2015.

Updates have been made to:

  • Transaction.auth()
  • Transaction.authCapture()

Ticket: CB-20138

Support Merchant Data (Name-Value Pairs) for AutoBillItem Object

The AutoBillItem object now supports Merchant Data (unlimited custom fields using name-value pairs) via the CashBox SOAP API (version 13.0 and greater.)

Merchant Data defined for a particular AutoBillItem will be inherited by the TransactionItem corresponding to that item for transactions generated as a result of that AutoBill (based on the data defined at the time the transaction is generated.)

Note This enhancement is only available via the API. Portal enhancement to allow manual creation and editing of the Merchant Data for these objects is forthcoming in Fall 2015.

Updates have been made to:

  • AutoBill.update()

Ticket: CB-20139

Bug Fixes

The following bugs were fixed in 13.0.0:

Ticket No. Summary Description


A problem with PaymentMethod.update() was causing inconsistent behavior with the method options replaceOnAllAutoBills and replaceOnAllChildAutoBills. Under some conditions, replaceOnAllAutoBills or replaceOnAllChildAutoBills with values of True were not respected, requiring the merchant to individually update the AutoBills.

This has been corrected in the current release, so that both parameters will be respected. If either or both cannot be acted upon, an appropriate response code will be returned.

For example:

With this fix, when the method is called to update an existing payment method that is already associated with an Account, the specified parameters will now always be respected: replaceOnAllAutoBills = true will assign this updated payment method to all of the active AutoBills on that Account, and replaceOnAllChildAutoBills = true will assign this updated payment method to all active AutoBills on all child Accounts of that Account.

But if these parameters are set to true in conditions where it is not possible to update the Account/Child AutoBills (such as when the payment method is still unassociated to an account), if the update otherwise succeeds the call will now return a 228 response, so that calling systems can programmatically be made aware that the payment method update succeeded, but that the automatic assignment had issues that might need to be investigated.


Rolling Billing period discounts don’t apply to specified number of billing cycles.

Problems reported where a rolling discount was improperly applied to only part of the specified run were resolved in prior release. In 13.0 additional tests were put into place to cover all reported scenarios, ensuring the expected behavior.


AutoBill giving free service if priced in currency with a token payment method.

Previously, no error was given when a user or API call changed an AutoBill's payment method to one that uses Tokens and the plan or any of the AutoBill Item's did not have a Token price defined. This led to an ambiguous situation where the charges were uncollectable.

CashBox will now return an immediate error (Error Code 400, Currency on BillingPlan does not match AutoBill PaymentMethod Type) if an attempt is made to change an AutoBill's assignment to a Payment Method that does not allow charging for or collecting on all of its associated items.


Entitlement.fetchByAccount() returns incorrectly deactivated entitlement.

Modifying an AutoBill with an effective date of nextBill caused the entitlement corresponding to a product being removed to be returned as deactivated prematurely. When initially modified, fetches for the Entitlement showed the entitlement remaining active until the start of the next billing period (as it should); a later call on the next calendar day erroneously showed that entitlement as deactivated. This has been resolved in the current release – so that the status of entitlements in this pending situation will be accurately presented.


CampaignId is not always populated in one-time transactions.

When a campaign was used on a transactionItem, the discount was correctly applied and shown, but campaignId was not always populating in either the Transaction.authCapture return, or the subsequent Transaction fetch. This has been resolved in the current release.


AutoBill.fetchInvoice() occasionally returned 500 errors.

Fixed a character encoding issue that would occasionally cause AutoBill.fetchInvoice to return a 500 to the merchant (when excessively long or malformed character values were encoded.)

CashBox for
Salesforce (Basic)

Learn More
CashBox for Salesforce (Basic)


Learn More

CashBox for
Salesforce (Premium)

Learn More
CashBox for Salesforce (Premium)
Back to Top