Cost Recovery System

From Dryad wiki
Revision as of 08:36, 26 April 2013 by Laura (talk | contribs) (See Also)

Jump to: navigation, search
  • Atmire has performed an initial analysis of the technical options for integrating a payment system into DSpace. (2012-2-28)
  • Ryan has reviewed the available systems for high-level features. (2012-11-15)
  • Atmire has performed a technical analysis of the candidate systems. (2012-11-15)
  • The finance committee has selected Bank of America to handle our primary banking needs. (2013-1-11)
  • Ryan and Laura have performed more detailed analysis on the payment processors and bank accounts. (2013-1-12)
  • The finance committee has selected PayFlow as the gateway for handling transactions. (2013-1-18)

Summary PPT

There is a PowerPoint Summary of the key issues on this page, along with wireframes for the new submission pages.


Dryad's Cost Recovery System must meet the requirements below:

  1. There must be a method to collect payment from depositors who are using the "Author Pays" (also known as "Pay-on-Submission") option.
  2. Payments should be advertised at the start of the submission process.
  3. Payment information should be collected at the end of the submission process (so authors have a chance to upload their data first, much like a shopping cart for online purchases).
  4. The payment information will be validated at the end of the submission process, prior to placing the submission in the curation queue.
  5. Payment should not be charged until the associated content is archived in Dryad. We can collect payment information and authorize the charge during the initial submission process, but we don't want to process the payment up-front in case the submission is rejected. This but does not require interaction from the depositor. The depositor completed their part earlier in the submission process.
  6. Subscription plans:
    1. On the initial submission page, when a journal is selected, Dryad checks to see whether the journal has a subscription plan.
      • TECH: Query goes to external journal database in Association Anywhere. The query checks for any valid subscription plan, including a "publisher voucher" plan with existing credit.
    2. If the journal has a valid subscription plan, the data deposit continues as normal, with no fees assessed.
      • TECH: The actual subscription fees will be processed by administrative staff, using Association Anywhere. This is outside the normal Dryad software.
    3. Note that these requirements actually cover three separate subscription plans, the normal "subscription" plan, the "publisher voucher" plan and the "deferred payment plan". The implementation within Dryad is the same for all.
  7. Single-use vouchers: There will be a system to create and manage the use of vouchers.
    1. A single-use voucher covers the entire cost of a "normal" submission. The voucher works regardless of whether the submission is associated with an integrated journal and/or a member journal. However, the fees for large data files DO apply to  submissions associated with single-use vouchers. These large file fees must be paid by the depositor.
    2. Single-use vouchers will be in the form of "gift cards" or "coupon codes" that an author can enter at payment time.
      • TECH: Single-use vouchers will be created and tracked in Association Anywhere. When a user enters a voucher in the Dryad submission interface, Dryad will query Association Anywhere to verify that the voucher is valid. When an item is archived, Dryad will notify Association Anywhere that the voucher has been used.
      • TECH: When a voucher is used, it must be stored in the data package, so it can be included in reports.
    3. Single-use vouchers will be valid for a period of 5 years. At the end of 5 years, if the voucher has not been used, a the original voucher will be disabled and a new voucher code will be generated.
      • TECH: Each voucher will be associated with a customer account in Association Anywhere, allowing a new voucher code to be issued to the customer when an old code expires.
  8. Pay on Submission:
    1. On the initial submission page, if the user selects a journal that does not have a subscription plan, the user will be notified that their submission will cost a certain amount.
    2. When the submission is ready to submit to curation, if a charge is active, the user's payment information will be collected. This information will not be stored on Dryad servers. Rather, it will immediately be sent to the appropriate payment processor.
      • TECH: Payflow zero-dollar-authorization
      • TECH: If the payment processor indicates that the payment information is invalid, the user is asked to submit new payment information before proceeding.
      • TECH: If the payment processor indicates that the payment information is valid, a transactionID will be returned to Dryad. This information should be stored in the Data Package item.
      • TECH: The transactionID will only be visible to curators/administrators. It should not be visible on the item pages for items with the "in review" status.
    3. Curators should always be able to view an item's payment status.
      • TECH: payment charge and transaction ID are stored in the data package. This metadata is not propagated to external APIs (OAI-PMH, DataONE, etc.)
    4. When an item is archived into the repository (after curator approval), the previous transactionID is used to submit the charge to the payment processor.
      • TECH: If the transactionID is invalid/expired, the curator will return the data package to the submitter. The submitter will need to re-enter their payment information.
    5. The submitter receives a confirmation email when the item has been archived. This email should include an indication of the amount charged.
    6. The submitter receives a separate email that contains a receipt for the transaction. The receipt contains a concise description of the transaction, including any confirmation code received from the payment processor.
    7. Users should not be required to create an account with the payment provider.
    8. Credit card information should never touch Dryad servers.
    9. NOTE: The member discount does NOT apply to the fees for pay-on-deposit.
  9. Non-integrated journal surcharge: If the submission is associated with a journal that is not integrated (as listed in, a surcharge is applied. This surcharge should be listed separately on the initial submission page, the payment page, and the confirmation email.
  10. The payment processor must accept multiple currencies, including GBP, USD, Australian dollar, Canadian dollar, Euro, Japanese Yen.
  11. Waivers will be granted automatically for authors from low-income countries. Authors will assert that they belong to an institution in a low-income country. Curators will verify this information before approving the fee-free submission.
  12. There will be a surcharge for upload of large files (over 10GB).
  13. We will not charge sales tax.
  14. When an item moves from review to curation, authors must be sent an email reminding them of the upcoming payment (including contact information if they need to change anything).
  15. All prices must be stored in a configuration file.

Notes on Timelines

  1. We do not yet have a hard timeline on the API for interacting with Association Anywhere. Until this API is available, we will set up a test journal that is hardcoded to simulate each potential subscription status.
  2. Dryad is currently investigating technologies for transfer of large files. Until this technology is in place, we will not assess the surcharge for large files. However, the payment system should be designed to include this in the near future.

See Also

The Cost Recovery System Wireframes illustrate how these requirements will be integrated into the Dryad submission interface.

For more details on Dryad fees and payment options, see:

Usage Scenarios

There are some usage scenarios that we want to remember for development/testing purposes.

  1. User submits, but their credit card cannot be processed. The card may be expired, or the payment processor may not be working. What errors will the user see, and what should they do next?
  2. User submits, and credit card is validated. But when the curator tries to archive the data, the credit card is no longer valid, so the payment fails.
  3. User submits. Before curator approval, the user decides to use a different credit card. Or switch from a credit card to a single-use voucher.
  4. User submits. After curator approval, the user decides to use a different credit card.
  5. User submits. Before curator approval, the associated journal buys a subscription plan.

Supporting Documentation

More detailed documentation describing aspects of the cost recovery system:

Open Questions

Questions that still need to be answered:

  1. How long should we keep a card number before charging it? If someone submits content for review and that content is approved a year later, should we still process the payment? Or should we have them re-authorize the transaction? (Note: PayFlow will expire the information after a year.)

PayFlow Payment Gateway

PayFlow is a gateway operated by PayPal, but ties into an external merchant account. It was originally developed by VeriSign. It was previously known as "Website Payments Pro".


  • Do they have an easily-reachable helpdesk? 7:00 AM – 8:00 PM CDT, Monday – Friday.
  • What currencies can they handle? Many (see bottom of FAQ page)
  • Virtual Terminal for processing phone, fax, and mail payments.
    • exports data to Excel, QuickBooks or Quicken
  • PayFlow products comparison
  • PayFlow Link is the basic system
    • Requires that we use their hosted pages for all forms. Doesn't allow complete customization of the forms. Their forms include some PayPal branding, which is undesirable.
    • Cannot process sales transactions through the API. This seems to indicate that we cannot process delayed "reference transactions" via PayFlow Link. (But it's not entirely clear.)
  • PayFlow Pro is the full-featured system
    • Definitely allows all of the features we want.
    • Adds capability for ACH transactions.
  • Developer site
  • Gateway Developer Guide and Reference
  • Transparent Redirect (only in payflow pro) = displaying forms on our site, but having them processed on paypal's site
  • They do not support unicode characters, only ASCII.
  • "secure token" = auth token for our servers to contact paypal servers
  • we will need to perform "zero dollar authorization" (TRXTYPE=A, AMT=0, VERBOSITY=HIGH), then do a "reference transaction"
    • reference tokens are valid for 12 months
    • "Only your account administrator can enable reference transactions"
  • express checkout = very simple system that requires customers to have a paypal account. Allows for authorization/capture, but not a true delayed payment.


Bank of America Merchant Account

BOA operates a merchant account that can interact with several gateways:

  • FirstData (owned by Bank of America)
  • PayFlow


See Also