Cost Recovery System

From Dryad wiki
Revision as of 11:02, 9 April 2013 by Laura (talk | contribs) (Open Questions)

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 mockups for the new submission pages.


When Dryad begins charging for submissions:

  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 subscription fees will be processed by administrative staff, using Association Anywhere.
    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 technical implementation is the same for all.
  7. Single-use vouchers: There will be a system to create and manage the use of vouchers.
    1. Single-use vouchers will be in the form of "gift cards" or "coupon codes" that an author can enter at payment time.
    2. 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 foucher will be disabled and a new voucher code will be generated.
      • TECH: Single-use vouchers will be created and tracked in Association Anywhere. Each voucher will be associated with a customer account, allowing a new voucher code to be issued to the customer when an old code expires.
    3. 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.
  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 item metadata. 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, any confirmation code that is 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. Surcharge for large files (over 10GB)
  13. We do not (currently) need to 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).

For more details on Dryad fees and payment options, see the final report from the 2011 Dryad Consortium Board Meeting and Business Plan and Sustainability

Pay On Deposit Mockups

See a separate page containing Mockups for the Pay On Deposit system.

Payment System Flowchart

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