Sorry this is long, but I've spent the last six months co-writing a Perl application that does exactly those four things(!) And interestingly for your purposes, our startup was so intent on making sure that our project got done ASAP to beat competitors to market that, as a risk-management insurance policy, we hired an outside firm to implement the project in Java. So this is an issue dear to my heart. (A couple of us inside guys have been building it in Perl.)

I'm tempted to give you my perception of the Java/Perl tradeoffs straight but I understand that's not what you're asking for. ;) To answer your immediate question: "How would you show Perl in the best light..." your best approach is to define or redefine the problem as a text-manipulation problem. Perl is just a much, much better and easier tool for handling text, due largely to regexp stuff that is awkward, missing, or slow in add-on Java libraries and oh-so-useful when you know how to employ it. And XML at least, and to a lesser degree, 'serving database information' (redefined as formatting db info for viewing) both tend to be heavily text-manipulation-intensive tasks, right? So that shouldn't be a hard sell.

Credit card stuff may be a little tricky until you get it working, but frankly, it's only a page of code or so and its been done a zillion times in either language. Use LWP or Net::SSLeay to open a secure (SSL) connection and munge your data so it fits the format the credit card processing company wants. And besides various libraries (signio? haven't used it), some credit card companies will point you to sample perl source which demonstrates my point that its really not much more than a page of code you stick in a subroutine somewhere. (Plus whatever custom exception handling you want to perform when cards are rejected.)

Managing user accounts? Well, I can't think of an advantage one way or the other unless you try to develop some scheme to piggyback your application's user account mechanisms on top of system-wide usernames/passwords in which case perl may have UNIX hooks (or string processing) which make it better.

Taint is clearly a unique feature useful for the highly-important security aspects. Depending on the client's biases, you may be able to convince them that obscurity is not security, and that critical open source perl/cpan hashing and encryption routines are heavily scrutinized by black and white hats worldwide and not just thrown together in some ISV's back room with a hope that since nobody sees the source, they'd have to get lucky to break it and that's an acceptable business risk for the ISV.

Taking my advocate's cap off, it's not the quality of the language; the quality of the programmers is a much bigger factor that swamps language differences. The following paper gave me some empirical data that validated my perceptions on that score, as an interesting attempt to quantify productivity and other issues among the various languages: An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program. (Note that the task that was studied was text/script oriented to begin with and thus not fully representative of any/all situations. I wouldn't depend on the paper for gospel truth, but it's great when you can make a nice generality about Java code-bloat and then, when challenged, be able to point to at least one academic study investigating that. It's not proof, but its better evidence than handwaving.)

So how did our Java and Perl teams fare when going head-to-head? Well, the details get complicated but basically, the 2 Perl coders beat out the 2-5 (it varied over time) Java programmers in delivering something to ship to market that runs reasonably reliably and scales at least decently under mod_perl. Now Perl-vs-Java wasn't the only variable at work, so there could be other factors coming into play (motivation differences, understanding of the specs and application were different, start/finish goal posts were not identical, etc). So it's not a clean win. But perl can definitely compete for these mid-size projects; don't let some fancy Java shop intimidate you! :)

While I'm only a Java novice, from what I can tell, Java forces you to do a lot of extra typing/infrastructure work to get something done. (Visual Age might reduce that somewhat, although it wouldn't seem to reduce the ongoing maintenance burden of that infrastructure.) So its not necessarily optimal for time-to-market. (Better than tracking down C buffer overflows or pointer errors though, true. Which is precisely how corporate America got sold on Java- as a internet-(buzzword)-oriented 3x programmer productivity boost over C, a better C++.) But I do have the suspicion that as you start to grow projects beyond, say, 5-10 programmers, you end up having to mimic a lot of the practices Java forces on you that otherwise Perl makes optional. But it sounds like for your client this won't be a critical issue.

I'd say sell him on your excellence, and make sure that such excellence comes across as 'responsible excellence' (documentation, coding stds, etc.), avoiding cowboy stereotypes. You already know you won't get shot down for pure buzzword compliance, since they're willing to consider Perl. Just portray yourself as the leaner, meaner competitor to a shop that probably does Java just because they can charge the client more for it, not because its a better solution. ;)