Cost Recovery System

The Cost Recovery System manages payments for data deposited to Dryad.

Overview
The Cost Recovery System includes:
 * Determination of which payment plan will be applied to a submission.
 * Transaction tracking for journals with subscriptions.
 * Creation and tracking of single-use vouchers.
 * Integration with a payment processor for author-pays submissions.

Usage
When a submission is initially created, the journal name is used to determine which payment plan will apply to the submission. As the user progresses through the submission process, they may view and modify payment settings.

TODO: Add step-by-step instructions, with screenshots highlighting the use of the feature. This may include a workflow diagram.

Technical Documentation
Cost Recovery System Technology

Summary PPT
There is a [[Media:2012-11-DryadBoardPaymentSystems.pptx|PowerPoint Summary]] of the key issues on this page, along with wireframes for the new submission pages.

Requirements
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:
 * 7) On the initial submission page, when a journal is selected, Dryad checks to see whether the journal has a subscription plan.
 * 8) *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.
 * 9) If the journal has a valid subscription plan, the data deposit continues as normal, with no fees assessed.
 * 10) *TECH: The actual subscription fees will be processed by administrative staff, using Association Anywhere. This is outside the normal Dryad software.
 * 11) 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.
 * 12) Single-use vouchers: There will be a system to create and manage the use of vouchers.
 * 13) 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.
 * 14) Single-use vouchers will be in the form of "gift cards" or "coupon codes" that an author can enter at payment time.
 * 15) * TECH: Single-use vouchers will be created and tracked in Dryad. When an item is archived, Dryad will validate the voucher.
 * 16) * TECH: The voucher code should be re-validated when a submission is resumed and when the Checkout screen is entered. There is a chance that the user will enter a valid voucher code, but the submission will not be completed immediately, and the code could become invalid before the submission is complete.
 * 17) * TECH: If a curator attempts to archive an item and the payment method is invalid (either credit card or voucher), an error should be displayed. The curator will then return the submission to the user's workspace and ask the user to enter valid payment information.
 * 18) * TECH: When a voucher is used, it must be stored in the data package, so it can be included in reports.
 * 19) Single-use vouchers will be given a "batch number", so all vouchers created in a single batch can be viewed and managed together.
 * 20) Single-use vouchers will record the ePerson who created them.
 * 21) 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.
 * 22) *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.
 * 23) Pay on Submission:
 * 24) 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.
 * 25) 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.
 * 26) *TECH: Payflow zero-dollar-authorization
 * 27) *TECH: If the payment processor indicates that the payment information is invalid, the user is asked to submit new payment information before proceeding.
 * 28) *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.
 * 29) *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.
 * 30) Curators should always be able to view an item's payment status.
 * 31) *TECH: payment charge and transaction ID are stored in the data package. This metadata is not propagated to external APIs (OAI-PMH, DataONE, etc.)
 * 32) When an item is archived into the repository (after curator approval), the previous transactionID is used to submit the charge to the payment processor.
 * 33) *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.
 * 34) The submitter receives a confirmation email when the item has been archived. This email should include an indication of the amount charged.
 * 35) 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.
 * 36) Users should not be required to create an account with the payment provider.
 * 37) Credit card information should never touch Dryad servers.
 * 38) NOTE: The member discount does NOT apply to the fees for pay-on-deposit.
 * 39) Non-integrated journal surcharge: If the submission is associated with a journal that is not integrated (as listed in DryadJournalSubmission.properties), a surcharge is applied. This surcharge should be listed separately on the initial submission page, the payment page, and the confirmation email.
 * 40) The payment processor must accept multiple currencies, including GBP, USD, Australian dollar, Canadian dollar, Euro, Japanese Yen.
 * 41) 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.
 * 42) There will be a surcharge for upload of large files (over 10GB).
 * 43) We will not charge sales tax.
 * 44) 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).
 * 45) All prices must be stored in a configuration file.
 * 46) When prices are changed, users are charged either the price they originally saw, or the current price, whichever is lower.

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.

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.

Final Wireframes

 * Wireframes for the Cost Recovery System system.

Supporting Documentation
More detailed documentation describing aspects of the cost recovery system:
 * Wireframes for the Pay On Deposit system.
 * Payment rate flowchart
 * Coming eventually -- API details for Association Anywhere

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.)