draft
invoice means you haven't yet authorized Digital River to capture any charges. However, draft invoices do list the total taxes, fees, duties, and amounts for the goods rendered. As a result, they can be useful to include in billing reminders to customers.customerId
sourceId
currency
state
locale
shipTo
discount
collectionPeriodDays
billingOptimization
items
taxInclusive
taxIdentifiers
chargeType
customerType
upstreamId
POST/invoices/{id}/open
. Only draft
invoices can be opened. So, before sending the request, make you first determine the invoice's state
.metadata
, can be updated. If you need to update customer or amount attributes, then void the invoice and create a new one.POST/invoices/{id}/void
request . This operation is similar to deleting an invoice but it allows you to maintain a record of when the invoice was created, opened, and voided.open
invoices can be voided. If an invoice is in any other state, and you attempt to void it, a 409 Conflict
is thrown:DELETE/invoices/{id}
request . This operation is similar to voiding an invoice but no record is maintained for accounting purposes. Only draft
invoices can be deleted.invoiceId
in a POST/refunds
.state
to open
, Digital River initiates a billing process and attempts to capture the charge(s). With invoices, you can take advantage of our billing optimization feature. If you use this feature, make sure your integration only displays payment methods that are supported with invoices.billingOptimization
to true
. This setting prompts Digital River to make multiple payment capture attempts throughout the billing period, the length of which you can configure by setting collectionPeriodDays
(the default setting is 30).state
to paid
. If the charge(s) are still not captured at the end of collectionPeriodDays
, we move the invoice's state
to uncollectible
and create an invoice.uncollectible
event.attemptCount
. This value can be useful for your analytics.billingOptimization
to false
, Digital River makes just one payment collection attempt. In this case, collectionPeriodDays
has no effect on the billing process. Depending on the result of that single collection attempt, we move the invoice's state
to either paid
or uncollectible
and then emit the corresponding event.billingOptimization
to false
, then you can allow customers to use any supported payment method to pay an invoice. This includes combining a primary source with one or more secondary sources.billingOptimization
is true
, then an invoice's payment.sources[]
should only contain a single source. Additionally, that object must be a primary source and it must support reusability. So, if you're using the billing optimization feature, restrict customers to payment methods that can be used in recurring transactions.draft
, open
, paid
, uncollectible
, or void
.draft
state can either be opened, which both transitions them to an open
state and initiates the billing process, or they can be deleted entirely.open
invoice can then transition to void
, paid
, or uncollectible
. All of these are terminal states. Invoices that are void
or uncollectible
are not payable.state
values for a successful invoice (i.e. the happy path) are draft
> open
> paid
.state
changes from open
to paid
both an invoice.paid
and an invoice.updated
event are emitted.draft
invoice.created
open
invoice.created
and an invoice.open
open
invoice.open
and an invoice.updated
paid
invoice.paid
and an invoice.updated
void
invoice.void
and an invoice.updated
uncollectible
invoice.uncollectible
and an invoice.updated