SEPA transfer

[nheinrichkl]

Hi,
I really like your implementation, I use it in our own club software. But I would really like to have "Sammellastschriften" via xml-file transfer and / or single transfers covered. This would help to save time in my club business :)

Is there a plan to implement this?

Kind regards
Norman

[farfromexact]

This request is reasonable, but SEPA transfer and SEPA direct debit are different workflows and should probably be scoped separately.

For the club use case, Sammellastschriften normally means a batch direct-debit file, while a normal single transfer is a credit-transfer file. The implementation needs to make the message family explicit, for example:

• pain.001 for credit transfers
• pain.008 for direct debits

For direct debit, the data model also needs creditor ID, mandate reference, mandate date, sequence type, collection date, and the bank-specific schema version. The library should validate the complete batch before writing XML and provide a dry-run or readable validation report; a partially valid file is worse than a rejected one.

I would first clarify whether the desired feature is an XML exporter for the club software or an actual FinTS submission flow. Those have different security and bank-compatibility requirements. A good incremental plan would be one versioned XML generator, fixtures from a few banks, deterministic output for testing, and an idempotency key so retrying a failed export cannot create duplicate collections.

[nheinrichkl]

Thanks for your reply. I created an export functionality to create a pain.008.001.02 xml file. With this file I do a manual upload via online banking. I think for the first step the FinTS submission flow should be sufficient.
My XML generator creates the quarter payment set for all our members. The xml is valid - at least for the Sparkasse :)
As there is a business account (or as in our case the club account) needed to test the xml transfer I can only support and test for this one bank. Would be glad to support here.

Norman

[robocode13]

It's nice that there is interest in extending the library to support transfer and debit functionalities but to be honest i don't think i will personally get to this any time soon. Of course i am open to contributions in this regard and could support this. There is already PR #27 which added the segments for SEPA transfer but as you can see from my comment #27 (comment) this is really only a small part of a complete transfer implementation.