This is a question that has two aspects to it: How you deal with your clients, and how your clients deal with your work.
The first is a business aspect, the second is a matter of QA.
I'm going to be somewhat optimistic, and assume that there's some way that they approve your work when you submit it. If there isn't, make it happen. This provides the basis for a stable working relationship, as it will make clear to both parties what it takes to work together and when things are going satisfactory.
Being an independent professional includes bargaining on stuff like this. You need to be able to function, otherwise you're paying for their incompetence. (in terms of Quality Assurance and Control)
I'd have to say that with a pay per task system, you're initially taking the burden of risk when it comes to bugs. That means that you have to plan for them, as they're inevitably going to happen. It also means you have to do a bit of your own QC and QA before you submit your work for approval, to minimise the risk of failure. Keeping track of your failure rate will improve your accuracy when it comes to making a good estimate on how long it will take you to complete a task until it has been accepted by the hiring company's QC department/process. Also, you need to make sure that a task is specified in clear and completable goals. (SMART)
If the client has no QA process whatsoever, then you're in trouble. If there isn't some kind of QC during acceptance, then there's no transfer of responsibility. You're stuck with the bugs until they're gone. This then enables them to play the blame game, forever. Some basic QC should take place upon accepting your work, or on a complete body of work that you have delivered (not points, but complete products/parts) that you deliver. Each task is like a mini project, and needs to be treated like one.
Now, if their QC has passed your work, it's up to them. If they throw it back on your plate after having accepted it before then it's a new job if you ask me. But this really is something that you and your client should have agreed on before commencing work. Maybe you need to (re?)negotiate this bit with your client.
As for x the points per day, that sounds like typical SCRUM-type agile work provisioning. I wouldn't have a problem with it, as long as your own estimates don't differ too much with theirs. It would help if you had a say in the estimate, but sometimes that's just not your call.
Some side notes on QA and QC:
- Quality Assurance is the process that ensures quality in the processes that are used to develop software. e.g. Planning that you will do quality control, process evaluations and and how to improve processes after finding faults.
- Quality Control is what you do to check that the product is doing what it is supposed to do. Things like setting up a unit test for a specific project etc. (including all the planning that is required to make it happen)
A company without a QA process is likely to have failures, which will probably mean that their code is likely to be buggy. Your code that has to integrate with it, and could suffer because of it. Implied QA is usually the same as no QA, as it's lacking structure, and therefore process improvement is very hard. (if not impossible) Having QC without guidance is then just a way to make it look good superficially.
QC should be the result of QA. There are a couple of systems that can help improve QA, like CMMI and SPICE (ISO/IEC 15504)