Envíos etiquetados con ‘micropagos’

Principal diferencia entre pago normal y micropago

Mayo 7th, 2010

La principal diferencia entre los pagos normales y los micropagos se encuentra en las comisiones que se cobran al realizar los mismos. Para entenderlo basta mirar estos datos:

pagar 1.00 euro -> comisión micropago=0.10, comisión normal=0.33
pagar 5.00 euros -> comisión micropago=0.30, comisión normal=0.45
pagar 10.00 euros -> comisión micropago=0.55, comisión normal=0.59
pagar 12.00 euros -> comisión micropago=0.65, comisión normal=0.65 (punto de encuentro)
pagar 14.00 euros -> comisión micropago=0.75, comisión normal=0.71
pagar 16.00 euros -> comisión micropago=0.85, comisión normal=0.76

La información se refiere a una entidad extrangera, ahora mismo no se de ninguna entidad española que trabaje con micropagos.

Comentar »

Enviado a Desarrollos

Etiquetas:

Configuración de un cliente OpenID con Spring Security y Grails

Abril 26th, 2010
Para este artículo se ha utilizado la versión 1.3.0.RC2 de Grails, OpenId4Java y la versión 3.0.2 de Spring Security. Como entorno de desarrollo estoy usando SpringSource Tool Suite.
Aunque Grails dispone de una serie de plugins para las configuraciones de seguridad de las aplicaciones, quiero mantener durante un tiempo los vínculos con el mundo J2EE tradicional por si por lo que sea hay que ‘reenfocar’ de forma rápida algún proyecto. Por eso por lo pronto prefiero usar Spring Security a la manera tradicional Java. La integración de Grails con Java es tan buena que permite hacer este tipo de cosas sin problemas. Esta técnica la aprendí en este artículo:

    Para crear la aplicación ejecutar desde la consola de comandos:

> grails create-app ClienteOpenID
Se puede ejecutar la aplicación para ver que todo va bien:
> cd ClienteOpenID
> grails run-app

    Instalar la plantilla web.xml

> grails install-templates
Este comando crea el archivo src/templates/war/web.xml que se debe editar para añadir después del último filtro:
<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

Y

<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Instalar las librerías

Una vez descargadas las librerías arriba indicadas al comienzo del artículo copiar en el directorio lib del proyecto Grails:

  • spring-security-config-3.0.2.RELEASE.jar, spring-security-core-3.0.2.RELEASE.jar y spring-security-web-3.0.2.RELEASE.jar de Spring Security.
  • las librerías openid4java-full-0.9.5.jar, commons-httpclient-3.0.1.jar, xercesImpl-2.9.1.jar, y nekohtml-1.9.7.jar que se pueden encontrar en la distribución del archivo openid4java.

Configuración del filtro de seguridad

Existen dos formas de configurar el filtro. Bien declarando los beans en grails-app/conf/spring/resources.groovy o declarándolos en grails-app/conf/spring/resources.xml, si se hace editando resources.xml:
<beans xmlns:sec="http://www.springframework.org/schema/security"
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:context="http://www.springframework.org/schema/context"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
              http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd
              http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">

	<sec:http>
        <sec:intercept-url pattern="/secure/**" access="ROLE_BUYER"/>
        <sec:intercept-url pattern="/login*" filters="none"/>
        <sec:logout/>
        <sec:openid-login login-page="/login" authentication-failure-url="/login?login_error=true">
            <sec:attribute-exchange>
                <sec:openid-attribute name="email" type="http://schema.openid.net/contact/email" required="true" count="2"/>
                <sec:openid-attribute name="transaction" type="" />
            </sec:attribute-exchange>
        </sec:openid-login>
    </sec:http>

    <sec:authentication-manager>
	<sec:authentication-provider user-service-ref="springSecurityUserDetailsService"/>
    </sec:authentication-manager>

</beans>
Con Spring Security se puede especificar en el archivo de configuración el tipo de información que se va a intercambiar con el proveedor del servicio OpenID. Si el proveedor ofrece esos servicios responderá con la información oportuna. En este caso intercambiaremos el correo del usuario que se quiera identificar, y un campo transaction en el que irá la información del micropago .
En el archivo se puede ver que para autentificar se utiliza el bean springSecurityUserDetailsService, este bean es un servicio que implementa la interfaz UserDetailsService que devuelve al autentificador una instancia de UserDetails. La instancia de UserDetails es una clase de dominio, la clase User, que implementa dicha interfaz.
Para generar mediante Scaffolding una aplicación para la gestión de una determinada clase de dominio, en este caso User:
>grails generate-all User
Y decir a todo que si.
Para probar la aplicación se vuelve a ejecutar:
>grails run-app
Y se introduce en la base de datos un usuario que tenga como propiedad Username el valor del identificador OpenID que quieras probar en la aplicación y como authority ROLE_USER. Para ello acceder mediante el navegador a http://localhost:8080/ClienteOpenID/ pulsar sobre UserController, e introducir un usuario.
El proyecto completo con todas las librerías se puede descargar desde aquí.
Para importarlo desde SpringSource Tool Suite:
File > Import > Existing projects into Workspace
Del código se deduce que vengo del mundo Java :-) . Hay varias cosas que con Groovy quedarían mucho mas elegantes, pero no hace falta saber utilizar Grails al 100% para poder ir sacándole poco a poco todas las ventajas que ofrece, de momento me siento más seguro sin dejar del todo el mundillo J2EE.
En próximos artículos explicaré como implementar el servidor OpenID que, en este caso, servirá para hacer transacciones utilizando como mecanismo de identificación el DNI electrónico.

Comentar »

Enviado a Uncategorized

Etiquetas:

Micropagos III – Flujo de operaciones que se producen en una transacción

Marzo 3rd, 2010

Introducción

OAuth es un protocolo abierto que busca estandarizar la forma en la que las aplicaciones acceden a datos privados albergados en servicios remotos. Este documento explica como se puede utilizar OAuth para realizar transferencias de dinero a través Internet.

El documento se puede descargar desde aquí.

Flujo de operaciones

En el flujograma de ejemplo participan:

  • El banco, prestador del servicio.
  • La entidad/persona beneficiaria de las transacciones, consumidora del servicio.
  • El usuario que dispone de una cuenta en el banco prestador del servicio y autoriza al consumidor del servicio a realizar un cargo.

Premisas:

  • Para que una entidad/persona pueda ser consumidora de servicio debe primero abrirse una cuenta con los bancos prestadores del servicio con los que quiera colaborar.
  • El usuario debe disponer de una cuenta en alguno de los bancos que el consumidor del servicio le ofrezca.

El usuario está navegando en el portal de un consumidor de servicio y decide hacer click en alguno de los enlaces que facilitan un micropago. El consumidor del servicio le ofrece los canales de los que dispone para poder recibir el micropago:

Para que el consumidor de servicio pueda utilizar el Banco de Internet debe disponer de una cuenta en el mismo. Durante el procedimiento de alta de cuenta se le ha proporcionado una clave de consumidor y un secreto de consumidor con los que podrá iniciar los intercambios de información con el banco.

Después de que el usuario haya seleccionado un banco empieza el intercambio de información. El consumidor de servicio solicita del banco un token de petición, en este punto de la conversación ese token todavía no tiene nada que ver con el usuario.

Cuando el consumidor de servicio recibe el token de petición envía al usuario con el mismo a la página del banco en la que se debe autorizar la transacción indicándole la URL a la que tiene que devolver al usuario una vez haya terminado la operación.

Una vez en la página del banco OAuth requiere que los proveedores de servicio autentifiquen a los usuarios antes de preguntarles si garantizan la operación.

OAuth hace posible las transacciones sin que los consumidores del servicio tengan que manejar información sensible (ni la contraseña ni el número de tarjeta).

Después de haberse identificado correctamente. El banco informa al usuario del beneficiario y la cantidad de dinero de la transacción que debe autorizar. Se puede usar el mismo mecanismo para autorizar pagos periódicos.

Una vez autorizada la operación por el usuario, el token pasa a estado autorizado en el proveedor de servicio y se redirecciona al usuario a la página del consumidor del servicio que inició la conversación.


Mientras el usuario espera el consumidor de servicio intercambia con el proveedor del servicio (el banco) el token de petición autorizado por un token de acceso.

En terminología OAuth los tokens de petición son sólo válidos para obtener el consentimiento del usuario mientras que los tokens de acceso se utilizan para acceder a recursos protegidos. En el caso que trata este documento el token de acceso tiene el siguiente uso:

  • La primera vez que se acceder con un token de acceso se finaliza la transacción autorizada por el usuario.
  • La segunda y sucesivas veces que se utilize el token de acceso el banco devolverá un recibo.

Referencias:

Guía para principiantes del protocolo OAuth


Comentar »

Enviado a Uncategorized

Etiquetas:

Tormenta perfecta

Marzo 1st, 2010
Hace un par de días vi en Informe Semanal un reportaje en el que los editores de los periódicos hablaban de que la crisis actual unida a lo que está suponiendo internet como medio de difusión de contenidos estaba suponiendo para ellos una especie de tormenta perfecta.
Se me hace muy difícil, imposible diría, llegar a imaginarme pagando por una subscripción mensual a un periódico. Lo que no se me hace para nada difícil imaginar es pagar por ejemplo 50 céntimos por tener acceso durante un día a los contenidos de un periódico … ó 30 céntimos por una mañana, ó 20 céntimos por una hora ó 10 céntimos por un contenido …
Los micropagos son fundamentales para poder encontrar el tipo de transacciones que pueden funcionar en Internet. Es un problema que no está resuelto … y dudo que acabe la tormenta mientras no se desarrollen al máximo, y de forma abierta, este tipo de fórmulas.

Comentar »

Enviado a Uncategorized

Etiquetas:

Micropagos II – Modelo de datos

Febrero 27th, 2010

La mejor manera de empezar una aplicación es haciendo su modelo de datos, para esta aplicación me he basado en este

Aunque hay varias opciones claras para poder usar clientes OAuth en Java, el tema de montar el proveedor es otra cosa, no hay mucha información y todavía no he visto nada claro, es aquí donde está el peligro. Ahora estoy jugando con una librería del proyecto Spring Security.
El modelo de datos sería para montar la entidad que prestaría el servicio de micropagos, por lo pronto lo he dejado sencillo, cuando tenga totalmente resuelto el tema del prestador de servicios le añadiré certificados electrónicos.

Comentar »

Enviado a Uncategorized

Etiquetas:

Micropagos I

Febrero 22nd, 2010

Oauth es una técnica que utilizan prestadores de servicios de Internet como Twitter, OpenSocial, Flickr, Yahoo, Google, Youtube, para exponer de forma segura a terceros los servicios que ofrecen a sus usuarios sin que tengan que viajar de un lado a otro las contraseñas.

Por lo pronto sólo he visto que se use en temas de redes sociales, pero no hay nada que impida que ese mismo patrón de interactuación pueda ser utilizado para ofrecer otro tipo servicios más ‘físicos’, me vienen a la cabeza aplicaciones de logística.

Dándole caña a la aplicación de gestión de firmas con DNIE electrónico traté con información que me hizo ver la posibilidad y ahora estoy cociendo un prototipo de sistema de micropagos que haría usando APIs OAUTH. El tema sería hacer ver una forma de crear aplicaciones que permitan hacer pagos de 50 céntimos o un euro sin cobrar comisiones a los usuarios … a ver lo que sale.

Poniéndose a imaginar lo que se puede conseguir con aplicaciones de este tipo, se puede llegar a formas de distribución de ayudas que podrían funcionar más o menos así:
• Creando un fondo que se repartiría entre todos los que quisieran participar, al final cada usuario dispondría de una cuenta con una asignación semanal que sólo podría gastar online siguiendo una serie de reglas acordes al problema concreto que se quiera solucionar.
• Cualquiera que quisiera acceder a los cobros se tendría que dar de alta en la aplicación y se tendría que buscar la vida explicando a los usuarios en su portal por qué se merecen la aportación.
• El sistema dejaría perfectamente reflejado donde y cuando ha ido hasta el último céntimo.
• En función de la evolución se podría crear un sistema de Karma que premiase asignando más recursos a aquellos usuarios que mejor hubieran distribuido su asignación en semanas anteriores.

… una especie de máquina de movimiento continuo autoregulada.

Si parte de los miles de millones de ayudas que han dado los gobiernos con el tema de la crisis se hubieran repartido de esta forma se sabría mucho mejor donde han ido.

Comentar »

Enviado a Uncategorized

Etiquetas: