We could have both really. All the API’s define is a framework for data exchange between the two parties.
The flow is initiated by the website creating a PaymentRequest and then calling show() (an unfortunate name because we are also looking at non-interactive use cases now).
The PaymentRequest is processed by a PaymentHandler which returns a response. (It’s simplest to think of a Payment Handler as a wallet that makes or authorises payments for the user).
All that we define in the payment method specification (the spec we need to write) is the data models in the request and response.
Push
In the push model we’d probably expect the website to put an ILP address and secret in the PaymentRequest (or a Payment Pointer). Things like the amount and currency are already present in the request so there is no need for those.
The Payment Handler (or something connected to it) would open a STREAM connection and make the payment.
The response from the payment handler could be made before or after the actual payment since the website is probably going to wait until it receives the payment via STREAM before it considers it complete.
i.e. The response is either a message to say “I have accepted your payment request and will now start paying it” or “I have accepted your payment request and finished paying it”.
Personally I prefer the former because it returns control back to the website faster which I think as a general rule is preferable.
Pull
The model I think is @sharafian is alluding to is for the PaymentRequest to have no ILP specific data but the response has a Payment Pointer from the Payment Handler (or simply an ILP Address and secret).
Once the website creates a STREAM connection using the details from the response it will begin pulling down the payment (details of how this will work are being discussed in the Pull Payments thread).
We could define a single payment method that supports both models. We’d need to look at the implications of this and possibly having multiple payment-method identifiers to allow the browser to filter out payment handlers that don’t support the method the website requires (push vs pull).