Format Tips

Prev Next

# Formatting Tips

These Tips apply to All Endpoints.

Tips

  • Cash Price: This is the Retail Price of the Good or Service being sold.
  • Down Payment: Amount consumer has paid toward the Cash Price.
  • Amount Financed: We calculate this by taking cash_price less down_payment
  • Description: Should represent the Good or Service being sold and also not include anything that would violate sensitive data like PII or HIPPA.

Date

  • Must be a date in the following format:
    • yyyy-MM-dd
  • Example:
    • March 1st, 1985 would be 1985-03-01
  • The zeroes prefixing single digit months/days are required, for example:
    • 1985-3-1 invalid
    • 1985-03-01 is valid

Phone Number

  • Valid Formats:
    • +15554446666

Currency

  • Valid characters: 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, and .
  • Should NOT include a currency symbol.
  • All currency fields are assumed USD. This cannot be overidden.
  • Should not include anything after the hundredths place, for example:
    • 486.452 invalid
    • 486.45 is valid
  • Never include ,. Only include . when specifying partial USD, for example:
    • 5,256.54 invalid
    • 5.256,54 invalid
    • 5256.54 is valid

State Abbreviations

Country Names

United States is the only allowed Country currently. Please use "United States"

Email

  • If you are able to use built in validation with jQuery or JavaScript, that is ideal.
  • Regex - refer to this website: emailregex.com

DocuSign Standard Responses

  • We leverage DocuSign for electronic signature. With our checkout endpoint you have a return URL that will receive this response. You'll want to design your code to take appropriate action based on the response.

  • Example

    • If the response code is "signing_complete", then this indicates a fully executed contract and your message would explain next steps to the consumer.
    • If the response code is "decline", then consumer Declined to sign the contract and thus didn't accept the financing option. Your message should represent this scenario and you would want to make sure any other systems you are updating treat this as decline and not a success.

From DocuSign Documentation

Determining Recipient Action

Once the embedded signing workflow is complete the recipient is re-directed to the value you provided through the returnUrl parameter. A query parameter in the form of ?event={event_type} is appended to the return url and can be parsed by your app to determine what action the recipient took. For example, if the return url is http://www.acme.com and the recipient signed the document the value would be:

http://www.acme.com?event=signing_complete

There are numerous actions the embedded recipient might take:

  • cancel - the recipient decides to finish later
  • decline - the recipient declines signing
  • exception - a processing error occurs during the signing session
  • fax_pending - if the recipient choses to print, sign and fax back
  • id_check_failed - if authentication was added to the document, this is when the recipient fails
  • session_timeout - the signing session times out when recipient goes idle
  • signing_complete - the recipient completed signing
  • ttl_expired - the token was not used within the timeout period or the token was already accessed
  • viewing_complete - a recipient that does not need to sign completes the viewing ceremony