Fundraising tech/New integration manual

From MediaWiki.org
Jump to navigation Jump to search

This is the development process to integrate with a new payment processor.

Preliminaries[edit]

  • Review documentation and confirm that the payment processor seems to comply with our technical, security, and communication standards.
  • Create test accounts.
  • Figure out the API endpoints and begin a discussion about stable IP address ranges for these servers, so we can add to the firewalls.

First milestone: ready for internal test[edit]

When this milestone is completed, we will be able to deploy code to staging or production which demonstrates some basic payment workflow. Fundraising and tech team members will be able to donate, along with selected testers in the target countries. We should not expose the page to the public at this point.

What we need for internal testing:

  • Working frontend form.
  • Backend processing workflow is able to make a charge and push the message onto the queue.
  • Tech team gives fr-online low-amount test links for target country / currency / language combinations

What we can skip for this step:

  • Audit processing. We can always pick these files up and import in the future.
  • Listener. Some workflows rely on the listener to finalize the payment, in this case we usually want to include that in the 1-hour test.
  • The queue message can't break the consumer. Not strictly necessary that we can import it correctly, however, this is sort of a grey zone.

Be sure not to publish the new form at this point. You will want to add the form definition in DonationInterfaceFormSettings.php, but set the selection_weight to 0 so that the form cannot be chosen without specifically naming it in the URL. We don't want donors accidentally navigating to the form.

Second milestone: 1-hour donor test[edit]

We will have a frontend stable enough to:

  • Provide decent donor user experience.
  • Process audit files and potentially listener messages, in order to send the donors their thank-you letters in a timely fashion. Ideally, this is a 100% thing, otherwise Tech and Donor Services will have to play catch-up.
  • Process payments in a manner that makes it possible for Donor Services to easily find, modify, and refund one-time and recurring payments in the payment processor console.

Final milestone: campaign-ready[edit]

We have iterated with 1-hour tests until we're certain that the bugs are ironed out.