We posted at the same time :)
Roberto: Yes, you can do what you describe, i.e. have the user choose either "pay by credit card" or "pay by micropayment account". Then your package will choose an implementation of the payment-gateway when "pay by credit card" is chosen or an implementation of the micropayments-gateway when "pay by micropayments account" is chosen. Next step is to advogate your service contract to package developers so that they make their packages aware of your new service contract. For example, modify the ecommerce package to use micropayment-gateway along with payment-gateway.
Everybody: To avoid confusion, in the given example, I say that the ecommerce package should be modified, for Roberto is talking about writing a new *contract* specification. There would be no need to change the ecommerce package or any other package that makes use of a contract when writing an *implementation* for that contract. For example, the ecommerce package will automatically support any new implementation of the payment-gateway, say for vendor "my credit card verification company XYZ".
Gilbert: There is not much in terms of documentation but the idea is pretty simple. Your best bet as Roberto has already pointed out is to check out the packages that either define a contract specification or provide an implementation of a contract. In loose terms, a contract is a set of abstract operations and an implementation of a contract provides one function for each abstract operation in the contract. Then the acs-service-contract package acts as a message redirector that calls the "right" function for a given contract, implementation, operation and arguments. For example, you say "acs_sc_call PaymentGateway [ad_parameter which_payment_gateway_implementation] AuthorizeCreditCard {1234-1234-1234 {Neophytos Demetriou}}" instead of "verisign_authorize {1234-1234-1234 {Neophytos Demetriou}}.
[Roberto, it seems that you posted again before I finished my message but I'm posting it anyway :) ]
