Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UsingQR – “Electronic” paper invoices using JSON and QR codes

people.skolelinux.org

Post reply on HN
Print view View original

21–28 of 28 posts

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#21

Post by dfox »

jon-wood wrote: post #11
dfox wrote: post #9

In Czech republic, QR codes that encode payment details for invoices are pretty common. It uses format called SPAYD for encoding of data which is variation of vCard formatting (as proposed in the begining of this article). Idea is that the same data in this format could also be transfered directly, but that is not so common, probably because there also is widely supported national standard for XML representation of e…

I routinely pay my cellphone bills by doing absolutely nothing (apart from having a skim of my bank statement now and again). In the UK almost all regular payments are done using Direct Debit, where you grant the company billing you permission to transfer the money automatically. Sadly it lacks the ability to specify an upper bound on that, but I've yet to have any issues in practice so I'm not massively worried.

In .cz you can also do that and even specify an upper bound (which is apparently mandatory as direct debit authorization for my credit card that got created automatically has upper bound of 999999CZK)

On the other hand I know many people who like me do not use direct debit for "unpredictable" things like cellphone bills. Most other payments can be automated by standing orders, what sucks that even when your monthly phone bill is essentially constant you cannot do that as our cell operators generally assign distinct payment reference for each monthly bill.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#22

Post by Loic »

randommodnar wrote: post #14
jon-wood wrote: post #11

Earlier quoted context omitted.

I routinely pay my cellphone bills by doing absolutely nothing (apart from having a skim of my bank statement now and again). In the UK almost all regular payments are done using Direct Debit, where you grant the company billing you permission to transfer the money automatically. Sadly it lacks the ability to specify an upper bound on that, but I've yet to have any issues in practice so I'm not massively worried.

Do not do this!!! If you end up in a dispute with your phone company, you are putting yourself at their mercy. It's waaay easier to fight a charge you haven't paid yet, then to recover money you've already paid. I've gone through hell because of this.

In Germany, for each direct debit entry in my ledger (in the web interface of the bank) I have a small button to revert the debit. I suppose this is standard because I have this button with the 3 banks I am banking with (business and personal).

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#23

Post by dfox »

jvhaarst wrote: post #10
dfox wrote: post #9

In Czech republic, QR codes that encode payment details for invoices are pretty common. It uses format called SPAYD for encoding of data which is variation of vCard formatting (as proposed in the begining of this article). Idea is that the same data in this format could also be transfered directly, but that is not so common, probably because there also is widely supported national standard for XML representation of e…

I would love it if my bank would start to use this, would save a lot of manual entry for inter person payments. Standard description : https://en.wikipedia.org/wiki/Short_Payment_Descriptor

There is slight problem with the fact that while it looks like pretty much country neutral system that is built on SEPA it in reality builds upon czech/slovak ABO system (Automated Banking Operations, which probably holds world record for government project with longest deadline overrun, as it was in development for almost exactly 20 years) and it's data fields for automatic identification of payments (X-VS, X-SS and X-KS in SPAYD IIRC). While SEPA has even more powerful mechanisms for this it seems that they are not much used, maybe exactly because they are too powerful.

One thing that fascinates me is contrast between european giro banking systems and ABO in particular (where account number is just an ID/address and has no security implications) and checking account based system used in US where everithing seems to be somewhat backwards from what would make sense.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#24

Post by megapatch »

It seems like a big step in the wrong direction. Sending invoices on paper should become a thing of the past. But even if you are sending invoices digitally, then choosing a common format would be the first problem. There are already several existing formats, from Edifact to XML based Oagis, with no winner in sight.

Rest assured that these petty JSON, vCard or the like ideas have little chance to work in real life, specifically if you need to compress invoices into the space limitations of QR codes... Real life B2B invoices are much more demanding.

When it comes to payment information, that is much simpler to solve. You don't even need to QR encode that, relatively simple forms with human readable numbers can be read by modern smartphone banking apps. I have two different installed (two different Swedish banks), works with most of the invoices I get home. The few that still come on paper, that is.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#25

Post by SOLAR_FIELDS »

megapatch wrote: post #24

It seems like a big step in the wrong direction. Sending invoices on paper should become a thing of the past. But even if you are sending invoices digitally, then choosing a common format would be the first problem. There are already several existing formats, from Edifact to XML based Oagis, with no winner in sight. Rest assured that these petty JSON, vCard or the like ideas have little chance to work in real life, s…

I wish there was some sort of financial/billing organization that could lay the law down and establish one of these as standards, but since billing is such a broad topic we may be lost on that front.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#26

Post by yrro »

randommodnar wrote: post #14
jon-wood wrote: post #11

Earlier quoted context omitted.

I routinely pay my cellphone bills by doing absolutely nothing (apart from having a skim of my bank statement now and again). In the UK almost all regular payments are done using Direct Debit, where you grant the company billing you permission to transfer the money automatically. Sadly it lacks the ability to specify an upper bound on that, but I've yet to have any issues in practice so I'm not massively worried.

Do not do this!!! If you end up in a dispute with your phone company, you are putting yourself at their mercy. It's waaay easier to fight a charge you haven't paid yet, then to recover money you've already paid. I've gone through hell because of this.

Depends on the country. In the UK the Direct Debit Guarantee states that "If an error is made in the payment of your Direct Debit, by the organisation or your bank or building society, you are entitled to a full and immediate refund of the amount paid from your bank or building society". The system is used by millions; it's so common for bill payments that paying by another payment method often attaches an additional charge.

[edit] Oh, I guess you mean in the case of a regular payment of an uncertain amount, like a mobile phone bill. I use a pay-as-you-go plan where a direct debit takes a fixed amount out of my account each month, and if I overrun it then my phone stops working until I pay more. I'd definitely think twice before setting up a DD for a mobile phone contract.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#27

Post by yrro »

arnarbi wrote: post #17
userbinator wrote: post #15

Why JSON? QR can store binary data. Something like BSON would make a lot more sense, given the tiny amount of storage in a QR code. Even ASN.1 seems more appropriate than the silly data->ASCII->ASCII-structured-format->binary encoding that's going on here, and admittedly in a lot of other transport formats too.

Not wanting to start flame wars, but consider CBOR instead of BSON (which only really makes sense if you want to integrate with MongoDB). http://cbor.io/

I hadn't heard of this one before. I like that it has an RFC attached (RFC7049) which contains in the appendices comparisons to other similar systems such as MessagePack and BSON.
Post reply on HN