Support mandates created by online bank forms (eg. XML mandates)

[hanneskod]

Using autogiro's online forms. This produces a file that is sent to the user, in an xml format. These mandates, as far as I can understand, should then be added just like a paper mandate. The file contains a verification code, that appears to be the BankID signature. These files should be kept safe by the user, just like a paper mandate.

The online form version should be possible to add quite easily - it looks like it just needs a new mandate source. Apart from that it seems to work exactly like a paper mandate.

The form itself can contain custom fields, added by the payer recipient, and these are included in the xml file.

The signature is present as , and seemed to contain hexadecimal digits with dashes. The first four digits looks like the bank's clearing number.

<?xml version="1.0" encoding="utf-8"?>
<DocumentElement>
  <MedgivandeViaHemsida>
    <Formulärnamn>autgiro online formulär namn</Formulärnamn>
    <Betalningsmottagares_x0020_namn></Betalningsmottagares_x0020_namn>
    <Betalningsmottagares_x0020_adress_1></Betalningsmottagares_x0020_adress_1>
    <Betalningsmottagares_x0020_adress_2>
    </Betalningsmottagares_x0020_adress_2>
    <Betalningsmottagares_x0020_adress_3>
    </Betalningsmottagares_x0020_adress_3>
    <Betalningsmottagares_x0020_postnr></Betalningsmottagares_x0020_postnr>
    <Betalningsmottagares_x0020_postort></Betalningsmottagares_x0020_postort>
    <Bankgironr></Bankgironr>
    <Organisationsnr>nnnnnn-nnnn</Organisationsnr>
    <Autogiroanmälan_x002C__x0020_medgivande />
    <Betalares_x0020_namn></Betalares_x0020_namn>
    <Betalares_x0020_adress_1></Betalares_x0020_adress_1>
    <Betalares_x0020_adress_2>
    </Betalares_x0020_adress_2>
    <Betalares_x0020_adress_3>
    </Betalares_x0020_adress_3>
    <Betalares_x0020_postnr></Betalares_x0020_postnr>
    <Betalares_x0020_postort></Betalares_x0020_postort>
    <Betalarnummer></Betalarnummer>
    <Kontoinnehavarens_x0020_bank>bank</Kontoinnehavarens_x0020_bank>
    <Kontonr>nnnnnnnnnnn</Kontonr>
    <Kontoinnehavarens_x0020_personnr>nnnnnnnnnnnn</Kontoinnehavarens_x0020_personnr>
    <Övrig_x0020_info>
      <customdata>
        <name>custom field name</name>
        <value></value>
      </customdata>
    </Övrig_x0020_info>
    <Verifieringstid></Verifieringstid>
    <Verifieringsreferens>hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh</Verifieringsreferens>
  </MedgivandeViaHemsida>
</DocumentElement>

Importing should be possible using simply:

giroapp import newMandate.xml

The first thing I want is an XmlMandateParser to be used like so:

$donor = $xmlMandateParser->parse($rawXmlContent);

Donor might need new fields (verificationCode, customFields, ...).

AddCommand should support these new fields and the new mandate source etc..

[nonbinary]

I'll start working on this after the file hashes, I think. I'm still not 100% sure about the file specs. I'm thinking I should get in touch with Autogiro customer support and see if I can get any better specs from there...

[nonbinary]

Maybe it would be useful to keep the verificationCodes in a spearate database. They are legally important, and should be saved very carefully.

If we store them in the donor database, would that increase the risk that a user accidentally deletes the donor database, and looses all of their verification codes? Would it be easier to discover you're about to delete the codes if they are in a separate database? (I stick to my habit of wearing the tinfoil hat and being the voice of paranoia here)

[hanneskod]

Specs would be awesome!

All data associated with a mandate should be saved in the same location imho. The signature key is of of course important. But it's up to the user to keep it safe. I would definitely file my .xml files in some safe and durable way outside the giroapp db (as I do with my printed paper mandates)...

[nonbinary]

True. Along with the xml files, a user also has the option to download pdf files. These contain the same files. Proper usage would be to download both, print the pdf, import the xml. As this code is related to a specific mandate the same way that an ID/account combo is, it should be in an optional field in Donor. The customfield is tricky, as these could contain fields like telephone number. Maybe we could add them in the comment field? It would then be up to the user to move them to the correct field.

[hanneskod]

Donor can be Attributable in the sense that we can allow

$donor->setAttribute('custom_field_one', $myCustomValue);

// and

$donor->getAttribute('custom_field_one');

This can be used to save all custom fields in an attributes array in the database.

As extra suggar we can let the user specify that a custom field contans for example a phone number (and should be written to the phone number field instead of an attribute) by letting them speficy a XmlMandateMigrationMap under .giroapp/xml or similar. Something like

class MyCustomMap implements XmlMandateMigrationMap
{
    public function getXmlMigrationMap()
    {
        return [
            'custom_field_one' => self::PHONE_NUMBER,
            'custom_field_two' => self::MAIL_ADDRESS
        ];
    }
}

And this can be used to find the correct database field for each custom value..

But this can maybe be a feature for alpha-3 ??

[nonbinary]

Yes, sounds like a good approach. I'd say we start with attributes now, and implement the MigrationMap for alpha-3. I have contacted bank customer support, am awaiting answer on the specs. I have been waiting for quite some time. I think I need another approach.

[nonbinary]

I'm kind of have misgivings about this. I'm currently working on a web-frontend to the giroapp. It has a form for new paper donors, which is saved in a file. The information in this file will then be added to the donor database somehow. It also has a file upload space. Xml files in this directory should be added as new donors.

The only difference between how these two mandate forms are handled is the source. It seemed logical to me to save the paper donors in xml form, similar to the webpage mandates. I'll have some backend scripts that parse these files.

If the giroapp can handle the xml files, I don't need to handle these with my own backend scripts. But then I still need to handle the paper donors.

It would seem logical to me, in my situation, if giroapp either didn't handle the xml webpage donors, or if paper donors could be added in the same way as webpage donors...

[nonbinary]

Btw, the bank still hasn't answered about the xml formats. I'll try the bankgiro customer support instead.

[hanneskod]

Why not save the "paper mandates" as shell commands in simple one line script files.

giroapp add -n --name "$name" ...

Then if we let import read from stdin you could follow the same pattern with xml files.

echo "$raw_xml_content" | giroapp import

This way you'll have a unified way of processing queued actions. And you don't need to invent a custom xml file format.

[nonbinary]

That would make the system execute files that are uploaded through the web interface, and that breaks security in bad ways. An attacker could upload a shell script that could wreak havoc on the server. But yes, I get the idea. I'll likely dump it in a way that my python script can read, like YAML or JSON,

[hanneskod]

Yeah you are probably right. I thought there were some well definied way of aplying input filters on xml content though...