Talk:Fundraising system spec: Difference between revisions

Revision as of 21:56, 22 August 2012

Do we have anything currently working? or is this all a "start from scratch" thing. --ErrantX (talk) 20:24, 22 August 2012 (UTC)

Ok, so rather than clog up the main page too much.. here's an outline flow

Collecting "yes to gift aid" is simple enough. Taking the Paypal API as an example (the other API is unknown at this point - we probably need to get that information from SmartDebit) you generally, depending on the preffered flow, ping Paypal to request a redirect url & transaction ID.
Gift aid preference and transaction ID could be pushed into a queue (i'd use something high availability like resque or something) and the user directed to the gateway
Gateway sends them back, after payment, to a thank you page (along with transaction id). This triggers a (background) query the for further details (name, address, current status of payment etc.) which are added to the queue
Depending on the API's being used:
- Once payments are validated the gateway pings us with the transaction ID, a worker grabs the relevant queue entry and updates CiviCRM
- A background job regularly checks queue entries for their status (via the gateway API) & pushes them to CiviCRM as appropriate

This needs a lot of refinement but should work. I am not sure what we used in the past?? --ErrantX (talk) 20:56, 22 August 2012 (UTC)

@@ Line 1: / Line 1: @@
 Do we have anything ''currently'' working? or is this all a "start from scratch" thing. --[[User:ErrantX|ErrantX]] ([[User talk:ErrantX|talk]]) 20:24, 22 August 2012 (UTC)
+== Gift aid & payment processing ==
+Ok, so rather than clog up the main page too much.. here's an outline flow
+* Collecting "yes to gift aid" is simple enough. Taking the Paypal API as an example (the other API is unknown at this point - we probably need to get that information from SmartDebit) you generally, depending on the preffered flow, ping Paypal to request a redirect url & transaction ID.
+* Gift aid preference and transaction ID could be pushed into a queue (i'd use something high availability like resque or something) and the user directed to the gateway
+* Gateway sends them back, after payment, to a thank you page (along with transaction id). This triggers a (background) query the for further details (name, address, current status of payment etc.) which are added to the queue
+* Depending on the API's being used:
+** Once payments are validated the gateway pings us with the transaction ID, a worker grabs the relevant queue entry and updates CiviCRM
+** A background job regularly checks queue entries for their status (via the gateway API) & pushes them to CiviCRM as appropriate
+This needs a lot of refinement but should work. I am not sure what we used in the past?? --[[User:ErrantX|ErrantX]] ([[User talk:ErrantX|talk]]) 20:56, 22 August 2012 (UTC)