Topic on Talk:Fundraising tech/Ingenico Connect

Civi Payment Processor table notes

3
EEggleston (WMF) (talkcontribs)

payment_processor_type = the actual processor, like paypal standard, paypal express

  • labels and defaults for a bunch of password / url settings
  • need to add rows for ingenico webcollect, ingenico connect, adyen, amazon, d*local

payment_processor = a specific account with a payment processor

payment_token = a token for a specific donor and a specific account

required fields in civicrm_payment_token table:

  • contact_id (fk)
  • payment_processor_id (fk)
  • token (string)
  • created_date (date)

Foreign keys to payment_processor exist in these tables:

  • civicrm_contribution_recur
  • civicrm_financial_trxn
  • civicrm_payment_token

OK, so we should add our payment processor accounts to the payment_processor table...

  1. insert missing payment_processor_types (What to use for an implementation class here? dummy?)
  2. insert payment_processor rows
  3. insert account_relationship rows
  4. Update civicrm_financial_trxn based on gateway column in wmf_contribution_extra
  5. Use API methods to get and create PaymentToken objects when we need to
MEpps (WMF) (talkcontribs)

civicrm_payment_token is a table in civicrm that is a reference to the account information for a payment_processor. Meanwhile, the token field in the civicrm_payment_token table is the string reference to the token for the recurring payment.

MEpps (WMF) (talkcontribs)

Payment classes are subclasses of CRM/Core/Payment. There is also CRM/Core/DummyPayment (not exact), which we could subclass. Could we somehow link this to our custom code in our extension though? For globalcollect, we use the recurring_globalcollect extension (that is the only payment processor that runs recurring payments from the civi database).

Reply to "Civi Payment Processor table notes"