Changes and updates to the Digital River API.


  • You can now create Checkouts and Orders with a phoneticName parameter. The phoneticName parameter allows Customer Service Representatives and couriers who need this information to correctly pronounce a customer's name in Japan. See Japanese phonetics and divisions for more information.

  • You can now create Checkouts and Orders with a division parameter. The division parameter allows customers to provide their division within an organization when they provide their business addresses in Japan.

  • You can now only request refunds for amounts or percentages less than, or equal to, those available to refund on an order, order item, invoice, or invoice item


  • We've now made it easier to see the amounts available to refund for an order by adding availableToRefundAmount attributes to Orders.

  • You can now retry failed order refunds by making a new refund request when a refund fails.


You can now search for Orders using the following filters: submitted timestamp, accepted timestamp, complete timestamp, browserIp, chargeType, subscriptionId, and refundedAmount.


  • You can now create SKUs with description, image, and url parameters to power a first-class user experience.

  • You can now create Refunds for delayed payment methods (such as Wire Transfer and bPay) that require the handling of additional customer information.

  • You can now receive order.charge.capture.complete webhooks when an order charge capture is complete for all payment methods (including PayPal and Direct Debit).


  • You now have the option for Digital River to calculate the landed costs of your cross-border orders for you in the dutiesTotal attribute.

  • You can now receive an order.accepted webhook when an order has successfully passed Digital River's fraud checks and has a capturable charge.

  • You can now create Checkout items with a new freeTrial parameter.

  • Make it possible to create multiple tax identifiers of the same type for Customers or on Checkouts.


  • You can now create Checkout items with an aggregatePrice parameter that represents the aggregate (or quantity) price of that line item.

  • You can now receive a sales_transaction.created webhook as soon as we create a (costed) sales transaction for you.

  • You can now receive an order.chargeback webhook when a chargeback occurs for an order.

  • We have now extended the Orders endpoint so you can determine if an order item was for a subscription renewal.


We now create event webhooks for all events supported in production in test mode.


  • We now create refunds in a pending state and publish a refund.pending event. We removed the refund.created event.

  • You can now view detailed information about your costed sales and Digital River's payouts to you with the new Payouts, Payout transactions, Sales summaries, and Sales transactions API resources.


  • Checkout sourceId now uses the default source identifier of the customer.

  • We will return tax rates as simple amounts rather than percentages (0.067 not 6.75).

  • You can now receive order.charge.capture.pending, order.charge.refund.pending, order.charge.refund.complete, and refund.complete event webhooks. We no longer support the order.charge.capture.created, order.charge.refund.created, order.charge.refund.completed, and refund.completed webhooks.

  • Renamed order.charge.created to order.charge.pending and order.charge.capture.completed to order.charge.capture.complete.

  • We have now extended Checkouts and Orders to return a tax.amount for shipping choices.


In live mode, we will attempt to deliver your webhooks for up to three days with an exponential backoff; in test mode, we will retry four times over a couple of hours.


You can now sync your SKU records with Digital River more easily by upserting SKUs using the SKUs API endpoint.


We have now extended the supported list of valid US states to include territories such as Guam (GU).


We have changed item-level amounts, so they now represent the amount to pay for an item–inclusive of any item-level discounts.


You can now create Checkouts with shippingChoice parameters with zero-dollar amounts.


  • Orders now have a cancelledAmount attribute, which represents the total charge amount cancelled.

  • You can now receive an order.charge.refund.failed webhook when a charge refund attempt fails for your customer's order.


We've made it easier to refund items by not requiring you to specify a refund quantity unless you want that quantity to be different from the ordered quantity.


  • You can now create an Order without first creating a Checkout by passing a Checkout request rather than a reference to an existing Checkout at order creation.

  • You can now create Checkouts with an aggregatePrice parameter that represents the aggregate price for a quantity of SKUs rather than their unit price.

  • Orders now have a capturedAmount attribute, which represents the total charge amount captured.

  • You can now provide an applicationId parameter when you create a checkout. You can use this attribute to segment your orders by application source.

  • You can now specify the ship from country or address in the Checkout with the new shipFrom parameter.

  • We have now added a sellingEntity attribute to checkouts and orders that you can use to display Digital River's Terms & Conditions and policies to your customers.

  • Digital River now validates the following addresses:

    • Checkout and Customer shipTo and shipping addresses

    • Source owner addresses

    This ensures the customer provided all address parameters required to successfully ship your physical goods anywhere in the world, to successfully create a payment charge, to comply with local invoicing regulations, and to calculate local taxes accurately.

  • Improved availability returns.

  • We will now return standardized card decline codes when you create an order, and the card networks decline the charges.

  • We have now added price and aggregatePrice attributes to checkouts and orders.


  • Improved availability refunds.

  • You can now receive a credit_memo.created webhook when a credit memo is created for a customer.

  • You can now receive an order.charge.created webhook when a charge is created for your customer's order.

  • You can now receive an order.charge.capturable webhook when a charge becomes capturable for your customer's order.

  • You can now receive an order.charge.refund.created webhook when a charge refund is created for your customer's order.

  • You can now receive an order.charge.refund.completed webhook when a charge refund completes for your customer's order.