The Adobe Sign Online Payments allows a sender to request a payment as part of the recipient's process (role agnostic). Payments can be defined as fixed values (quotes), values derived from calculated fields on the agreement (order form), or customer entered values (donations). The payments feature is available to the enterprise level of service in the NA, EU and AU datacenters.

Feature description

The Online Payment service in Adobe Sign integrates Braintree as a payment gateway tied to the signature process. The integration is enabled by adding a Payment field to your form.

Forms can be created with Payment fields based on the following:

  • A static value, as in the case of a quote for service
  • A dynamic value, derived from calculated fields on the form, as in an order form with multiple items, quantities, and shipping methods
  • A recipient entered value, like a donation request


Use of a payment field on the agreement changes the Click to Sign button to a Pay and Sign button when the value in the payment field is not null.


The Braintree integration inserts a payment window into the signer’s interface after they click the Pay and Sign button.  This window collects all the personal payment information, obviating the need for the signer to enter that personal information into an Adobe Sign form, improving the general security of the signer’s information, and eliminating the need for the sender to capture and manually process the payment. 


Online payments are not available for customer accounts in the JP1 or IN1 datacenters.

How it's used

Creating a successful payment form only requires you to use a Payment form field in the agreement.

If you are new to form authoring in Adobe Sign, you may want to take a moment to familiarize yourself with the in-app authoring tool.

Users familiar with the authoring process only need to learn about the new field type (Payment) and what is required to make it work properly.

Using Drag and Drop Authoring

The payment field can be found at the bottom of the list of field categories on the right side of the Authoring window



Applying the payment field requires careful attention to the field options to insure that your form functions properly.


Assigned to – Make sure you are assigning the field to the recipient that is expected to provide payment. This may seem counter-intuitive for a static payment value, but the assignment of the field is what logically relates the payer to the payment record.

Value Type – This is linked to the function of the form

  • Entered value gives you a static value, whether it be a stated value like a quote, or an accepted value, like a donation.
  • Calculated value gives you a derived value from a formula involving other fields. This is used for a dynamic order form.

Read Only – If checked, the sender must ensure that the field is populated either with a fixed value, or through a calculated value.

If unchecked, the value is either the default set during authoring, or the value entered by the recipient.

Default value – Used if your form has a set value for static payments, or a suggested donation value.

Currency – Set the appropriate currency for your target audience. 1000 Yen is very different than 1000 Pounds.

Value Range – Useful if you want to establish a bounded range for donation values.

2. Payment Field Properties

Static value (Quotes)

A form with a static value must have an Entered value established during authoring.

  • The field should be defined as Read Only
  • A  non-zero Default Value should be entered
  • Select the correct Currency for the targeted recipient
3. Static Value properties


The user experience shows the field and value, but does not allow the payer to alter the value.

Static value customer view

Dynamic value (Order form)

The dynamic value Payment field should be configured as a Calculated value.

  • The option to make the field Read Only is required for calculated values, so the option is removed from the properties menu 
  • The calculated value will be derived from other fields that the recipient can interact with (quantities, shipping methods, insurance options etc.)
  • During authoring, the formula is exposed in the field instead of a numerical value

Select an appropriate Currency

4. Calculated Value properties


The user experience is to see the field, the values of the field adjust in real time as options are selected, but the recipient is unable to directly interact with it. (Highlight added below)

Calculated field

Recipient defined values (Donations)

A signer defined payment field allows the user to directly enter the value of the payment. It should be configured as an Entered value, and the Read only feature should be disabled.

A default value is permitted, but can be freely edited.

A value range is permitted, and will be strictly enforced.  Meaning if you would like to restrict the lowest value acceptable, you may do so.

Donation Value properties


The user experience shows the field, and is fully editable, potentially with a default value if so designed.

If an upper or lower bound is defined and a value outside that bound is entered, an error will occur and the recipient will not be allowed to sign until the value is corrected.

Donation Input


If a zero or empty value is placed in the field, the Pay and Sign button will change to Click to Sign, indicating that no payment is involved with the agreement.

Null Value field


Negative values are not permitted

Negative value

Transaction Records

Ensuring that data is stored securely is a fundamental driving force when dealing with personal information such as payment details. Adobe Sign and Braintree only share the minimum necessary details to complete the transaction and ensure proper auditability of a payment as it is related to an agreement.

Braintree records

The Adobe Sign system is the custodian of the agreement documents, and records regarding recipients and interactions. At no time is Braintree aware of the content of the transaction or the full list of recipients. (By necessity, Braintree must be aware of the payer.)

At the time the Pay and Sign button is clicked, an I-frame is opened to the Braintree service, and four data objects are passed:

  1. The Currency type - Needed only to ensure that the correct merchant account is used in Braintree
  2. The number value in the Payment field – Needed to understand the value of the collection
  3. The email address of the Payer– Needed to identify the Payer
  4. The participation code of the transaction – Needed to directly relate the payment record to the Agreement record 

Adobe Sign records

Braintree is the custodian of the payment records, and no records related to the personal information of the payer is ever passed to Adobe Sign.

When the payment is successfully completed, only the Braintree transaction number is passed back to Adobe Sign. This transactionID can be found in the History tab (on the Manage page) 

6. History tab


and in the Audit Report:

Audit Report

How to enable or disable

Before you can start working with payment fields in Adobe Sign, you must have a Braintree account.

A production account can be registered here:


The Adobe Sign Online Payments feature can be enabled at the Account level by the Adobe Sign Account Admin.

  • Group level settings are permitted, and will over-ride the Account level values.
  • Each group can have their own unique Braintree account enabled.

To enable the feature, navigate to: Account > Account Settings > Payments Integration



Check the Enable Payments feature checkbox and click Save to prompt the Braintree credentials panel.

10. Braintree credentials

Copy and paste the requested information from your Braintree account into the credential panel, then click Save.

Changing your Braintree credentials

If you need to change the Braintree credentials (eg: changing to a new merchant account):

Navigate to the payment page: Account > Account Settings > Payment Integration

Check the Register a different Braintree account checkbox

Click Save

  • The overlay to enter the credentials appears

Disable Braintree

You can disable the integration between Adobe Sign and Braintree on the Payments Integration page of Adobe Sign: Account > Account Settings > Payment Integration

Uncheck the Enable Payments feature checkbox

Click Save



A challenge is issued to ensure that you want to disable the integration:

13. Disable Braintree account

If you anticipate that you will re-enable the integration with the same Braintree credentials, make sure that the Disable, but save my Braintree account for later use checkbox is checked.

If you uncheck this box, Adobe Sign does not save your authentication information, and you will need to re-enter it when the feature is enabled again.


Configuration options

The Braintree service offers a number of configuration options that can greatly improve your signer’s experience. Everybody has different needs from a payment service, and a thorough exploration of the Braintree features is well worth the effort.

With regards to the Adobe Sign integration there are a few features that relate directly to the signer’s experience:

  • Currency – What currency are you accepting?

Braintree accepts a wide range of currency types, and allows you to make a “Merchant account” for each currency you will accept. This merchant account further allows you to define what types of payments you will accept (PayPal and/or discrete credit cards).

15. Merchant account


Within Adobe Sign, the Payment field must be configured for one type of currency. This configured value links to the Merchant Account of the same currency type. 

The values listed in the Adobe Sign field properties are dictated by the currencies accepted in your Braintree merchant accounts.

Setting a default Merchant account will also define the default currency loaded in the Adobe Sign Payment field.

16. Currency


  • Duplicate Transaction Checking – Prevents a quick double-click from creating two transactions, and double-charging your signer.
17. Dupe Transaction

Things to know

PCI Content and Storage

During the payment process, all information is entered into the Braintree interface.

All payment information is stored solely within the Braintree account.

The Adobe Sign environment only stores the API credentials to the Braintree account and the Transaction number that is passed back from Braintree (recorded in the Adobe Sign Audit Trail).

No actual payment information ever touches the Adobe Sign system, ensuring optimal PCI compliance and signer security.

Disrupted transaction between Payment and Signature

When using payments, the signature process happens in two parts:

  • Capture the payment
  • Complete the signature

This ensures that the agreement can’t be completed without the payment being captured first.

If for any reason there is a disruption in the process, the signer is able to re-open the agreement from the original link (or a reminder link if reminders are configured), and resume the signature process.

If the payment was captured prior to the disruption, that information will be clearly displayed to the signer.

18. Distrupted sign - Payment made


The History tab also properly reflects this state.

19. Disrupted transaction history

Duplicate payment prevention

The Braintree service has a Duplicate Transaction Checking feature that prevents multiple transaction to the same transactionID within a set time span.  This prevents multiple payments from being logged due to multiple button clicks.

To configure the Duplicate Transaction Checking option:

1. Log in to your Braintree account

2. Navigate to Settings > Processing > Duplicate Transaction Checking

3. Turn the setting on

20. Dupe Transaction

Payment Disputes

Recipients that have a payment dispute for any reason should contact the party that sent the agreement by replying to the original "Please Sign" email.

Adobe Sign provides the platform for the signature process, but hands off the payment process to Braintree.

No payment, or payment information, is collected by Adobe Sign, we simply expose the payment portal that the sender of the agreement has configured.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy