Sofortüberweisung HandlePayment Notification
Closed, ResolvedPublic8 Story Points

Description

AC:

  • Accept request from sofortüberweisung backend (similar to the Paypal IPN) when the donation is successful
  • The fact that Transaction confirmation was received, is saved in payment metadata
  • Donation status (STATUS_PROMISE) is unchanged
  • logging of requests is performed
    • successful requests only in debug mode
  • The payment method will not respond to the feature toogle implemented for the FE
Pablo-WMDE updated the task description. (Show Details)Jun 14 2017, 1:50 PM
Pablo-WMDE set the point value for this task to 13.Jun 14 2017, 1:55 PM

It is not finally decided, whether this task will be carried out at all. There are three approaches and resulting implications we can outline:

  • Ignore payment notifications (making this task superfluous)
    • data sets will in every case have the same status as "Überweisungszusagen"
    • the transaction ID will be known, since it is created before redirecting to the payment provider
    • there is no distinguishing between cancelled and completed transactions
  • Payment notifications are partially processed (reducing complexity of this task)
    • data sets will in every case have the same status as "Überweisungszusagen"
    • the transaction notification for a specific data set is logged
    • since the transaction details are not retrieved from the payment provider, there can't be a guarantee regarding the payment status
  • Payment notifications are fully processed as described in the payment provider's documentation
    • data sets may have different statuses similar to other payment providers (e. g. incomplete, confirmed)
    • data can be analysed as a payment (considering the rare cases of successful transactions eventually not being carried out by the bank)

as discussed with Gabriel and Pablo I prefer Option 2. But we need to discuss wether we should adjust the WQ-Code to this kind of Überweisungszusage.

gabriel-wmde updated the task description. (Show Details)Jun 29 2017, 4:41 PM
gabriel-wmde changed the point value for this task from 13 to 8.
Pablo-WMDE claimed this task.
Pablo-WMDE added a comment.EditedJul 11 2017, 1:30 PM

Resources

Files

routes.php

app/RouteHandlers/SofortNotificationHandler.php
::handle()
::newUseCaseRequestFromPost()
::createErrorResponse()
::log()

Factories/FunFunFactory.php
::getSofortPaymentNotificationVerifier()
::getSofortLogger()
::newHandleSofortPaymentNotificationUseCase()

DonationContext/src/UseCases/HandleSofortPaymentNotification/HandleSofortPaymentNotificationUseCase.php
::handleNotification()
::handleRequestWithoutDonation() (can not happen with sofort)
::handleRequestForDonation()
::sendConfirmationMailFor()?

PaymentContext/src/ResponseModel/SofortNotificationResponse.php

PaymentContext/src/RequestModel/PayPalPaymentNotificationRequest.php

Q

  • /spenden/paypal_handler.php
  • what responses do we send on notifications?
    • would sofort repeat a notification if we answered 500?
  • bankTransferCode length: 13 at the moment vs 10 after T170266 - what should be in FundraisingStore after T167886
  • bankTransferCode native property of Donation. For sofort implemented as payment-type-specific information. Which approach to follow? Making it payment-type-specific would make the unique-check (UniqueTransferCodeGenerator) across all payment types more expensive, or require some form of code sharding
  • => save bankTransferCode in Donation (cp. alias for "externalId")

Created PR for sofort notification and donation confirmation mail: https://github.com/wmde/FundraisingFrontend/pull/921

Why on doing and not on review?

@JeroenDeDauw Because GB requested changes that needed me "doing" them; moved it back from "review" after the review. Now that you apparently took over, please feel free to adjust the status accordingly. Thanks!

I did not take over. The whole team is responsible for the tasks we pick up

Pablo-WMDE added a comment.EditedAug 2 2017, 2:30 PM
  • Put sofort and payment types feature toggle (with SUB enabled) in deploy's config.prod.json for test system
  • Put sofort (no valid config key, yet) and payment types feature toggle (with SUB disabled) in deploy's config.prod.json for prod system

Did the migration for test spenden_test database:

CREATE TABLE donation_payment (id INT AUTO_INCREMENT NOT NULL, payment_type VARCHAR(3) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE donation_payment_sofort (id INT NOT NULL, confirmed_at DATETIME DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
ALTER TABLE donation_payment_sofort ADD CONSTRAINT FK_2DF4845ABF396750 FOREIGN KEY (id) REFERENCES donation_payment (id) ON DELETE CASCADE;
UPDATE spenden SET dt_gruen=NULL WHERE CAST(dt_gruen as CHAR(20)) = '0000-00-00 00:00:00';
ALTER TABLE spenden ADD payment_id INT DEFAULT NULL, ADD CONSTRAINT FK_3CBBD0454C3A3BB FOREIGN KEY (payment_id) REFERENCES donation_payment (id);
CREATE UNIQUE INDEX UNIQ_3CBBD0454C3A3BB ON spenden (payment_id);

The UPDATE is necessary to remove invalid timestamps from the table.
Caution: The ALTER TABLE command will take 5 minutes to run!

Pablo-WMDE added a comment.EditedAug 2 2017, 4:30 PM

Sofort\SofortLib\Notification is a thing. Can be used to parse (what sofort apparently sends) the XML response body; can be accessed with $this->request->getContent();

Current situation in error log:

{"message":"Invalid notification time","context":{"post_vars":[],"request_content":"<?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<status_notification><transaction>151116-357759-5981F3FA-725C</transaction><time>2017-08-02T18:29:45+02:00</time></status_notification>","query_vars":{"id":"1872220","updateToken":"68d3abc39d327a56734d2b5057d12a56"}},"level":400,"level_name":"ERROR","channel":"sofort","datetime":{"date":"2017-08-02 18:29:45.649346","timezone_type":3,"timezone":"Europe/Berlin"},"extra":[]}
Pablo-WMDE removed Pablo-WMDE as the assignee of this task.

Deployed newest master to test

Prod deployment mysql changes

CREATE TABLE donation_payment (id INT AUTO_INCREMENT NOT NULL, payment_type VARCHAR(3) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE donation_payment_sofort (id INT NOT NULL, confirmed_at DATETIME DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

ALTER TABLE donation_payment_sofort ADD CONSTRAINT FK_2DF4845ABF396750 FOREIGN KEY (id) REFERENCES donation_payment (id) ON DELETE CASCADE;

UPDATE spenden SET dt_gruen=NULL WHERE CAST(dt_gruen as CHAR(20)) = '0000-00-00 00:00:00';

ALTER TABLE spenden ADD payment_id INT DEFAULT NULL, ADD CONSTRAINT FK_3CBBD0454C3A3BB FOREIGN KEY (payment_id) REFERENCES donation_payment (id);

CREATE UNIQUE INDEX UNIQ_3CBBD0454C3A3BB ON spenden (payment_id);

The UPDATE to dt_gruen=NULL caused a ripple effect for one record (id=1349447) which consequently was (redundantly?) exported via SpendenDumper on 2017-08-15. @tmletzko was notified to look for adverse effects in VEWA.

@tmletzko SUB can be tested at https://test-spenden-2.wikimedia.de/ with a configuration pointing to a test project on SUB's side. @kai.nissen wanted to setup the prod project.

@Pablo-WMDE I know about the test page. Don´t we have a test data set to test the actual process? Or do we have to set up a real account (however that works)

  • please chance account holder to Wikimedia Fördergesellschaft

@tmletzko

  • I'm afraid I don't know what it means to "test the actual process" then. Do you mean on our production?
  • The recipient name shown in the top left corner of the screenshot is not part of our application configuration, but - I assume - can be configured in the sofort backend (/cc @kai.nissen)

@Pablo-WMDE I would like to login and donate. I thought Sofort provides test data sets for that.

@tmletzko It's in the documentation for test transactions.

  • please change account holder to Wikimedia Fördergesellschaft

I changed the payment recipient's name accordingly.

on the confirmation page it says "Ihre Spende per Sofortüberweisung wurde zugesagt und wartet auf Buchung." I doubt that this is a wording that we want. Can we change that?

I rather have: "Ihre Spende per Sofortüberweisung wurde von uns verarbeitet." I guess SUB-users know that the payment is completed once I made the transaction.

tmletzko added a comment.EditedAug 16 2017, 2:04 PM

@kai.nissen can you provide me one of my test data sets (in csv export structure), so I can check with VEWA. Maybe you can combine SUB datasets with PPL members (as requested here: T162438). Easiest way would be hand over csv to Carsten or Tino.

export file including donations using Sofort and membership applications using PayPal provided by e-mail

Pablo-WMDE closed this task as Resolved.Mon, Sep 25, 11:29 AM