payment is created with OOFF contribution, but not with RECUR contribution

[lbl-knts]

this is a follow up to #Project60/org.project60.sepa#611

Hi @lbl-knts. There's some stuff to unpick here.

The extension seems to differ if it's a one-time or recurring contribution.
Use case: a filled public contribution page with one-time contributions >creates a payment entry< within the contribution.
While having recurring contributions, the extension >does not create any payment< entry.

Yes, that's by design. Recurring contribution create a recurring mandate, which only generates a contribution when the transaction groups are generated. One-Off donations will only be collected once, so the contribution is created along with the mandate.

Any hints for what this differ?

Yes, you should maybe have a look a the documentation here: https://docs.civicrm.org/civisepa/en/latest/

[lbl-knts]

Thanks @bjendres

In the manual i did'nt find an advise to answer the question. For me, technically in CiviCRM, if i recieve a event fee or a donation, a contribution is created. A payment should be created when the cash flows to my bank account.
The CiviSepaPP Extension creates a contribution with pending status and a payment with the date of the contribution (not the payment!) and status of completed, which seems incorrect to me. This only happens with OOFF contributions.
Would you point me to the place, where the payment is created?

[bjendres]

Thanks @bjendres

For me, technically in CiviCRM, if i recieve a event fee or a donation, a contribution is created. A payment should be created when the cash flows to my bank account.

That's correct. And the cash only flows, when you generate a SEPA group (via the SEPA Dashboard), and submit it to your bank. At that point there is going to be a contribution. You'll find information on the different contribution statuses being used in the documentation.

[lbl-knts]

Thank you for the reply, @bjendres.
The contribution entry gets created when a user has filled a donation/contribution site. Normally it supposed to create a CiviCRM-payment-entry (which is not the same as a contribution in CiviCRM) when a real-payment is done. This is what happens with CiviSepaPP on recurring contributions, everything goes well.
On one-time contributions, the CiviCRM-payment-entry is created while the user has filled the forms on the contribution site, which means before the real-payment is passed (and before generating the SEPA group). And this is by design?

It would be nice if you point me to the place where OOFF-payment is created.

[bjendres]

On one-time contributions, the CiviCRM-payment-entry is created while the user has filled the forms on the contribution site, which means before the real-payment is passed (and before generating the SEPA group). And this is by design?

Yes, that's by design. If you look carefully, you see that the SEPA OOFF contributions are first in status Pending, the In Progress and only get marked as Completed when the SEPA group is marked as received. It's the same with SEPA RCUR contributions, except they don't get created when the donation page submitted.

Does this answer your question?

[lbl-knts]

Thank you again @bjendres.
I'am asking for some side effects (lets say regarding "CiviCRM-technique"), following the payment entry.
i want to point out three things.
First, if i want to record a payment (not with CiviSepa), there is already a payment entry.
Second, normally the contribution status is set to pending and gets changed automatically after i have recorded a payment. With the contribution status set on "pending" with the CiviSepaPP, the automatic switch does not work after recording a payment (because there is one already).
And third, with this automatic switch of contribution status, there are a couple of things going on in CiviCRM, for example changing the status of participant (from pending to registered). This use case also apply to memberships/CiviMember.
In summary, the Extension works very well with recurring contributions, and i'am wondering what it needs to be fully functional for OOFF contributions, too.

[bjendres]

You're probably right about your three points - assuming your still talking from the perspective of the payment processor.

Currently the payment processors are pretty neglected from our end, because not a lot of people (we work with) are using them (too unflexible).

Since you clearly do, and seem to have a specific use case in mind, feel free to contribute.

[lbl-knts]

Thanks, @bjendres. I will come back to this later.