payment api (jsr 229)

JOSÉ ANDRÉ HENRIQUESLUIZ TIAGO OLIVEIRA

RAFAEL ROCHARICARDO DAMASCENO

Mobile Payment APIJSR - 229

Mobile Payment API

Roteiro1. Histórico e literatura relacionada2. Estado da Arte3. Escopo e Requisitos4. Arquitetura5. Comunicação6. Pacote7. Provisionamento de Dados8. Segurança9. Adapters10. Conclusão11. Bibliografia

Histórico

01/04/2004 Draft inicialReleases (principais adds)

abril/2004 suporte a localização, Pay-Debug-DemoMode, capítulo de segurança, redefinição formato SMS, etcmaio/2004 novos métodos para TransactionRecordssetembro/2004 removeu métodos gets, mudou TransactionRecord de class para interface, registro na IANA, publicação do Draftnovembro/2004 atualizou UML, formato SMS livrejunho/2005 Draft final proposto

30/06/2005 release final

Estado da Arte

Consolidado em países como Japão, Estados Unidos, FrançaMac Donald’s – JapãoMoneo - França

Estado da Arte

MobiPay – EspanhaJoint Venture entre todas as operadoras móveis e 80% dos bancos

União de bancos e operadoras de telefonia celularpagamento de taxi e transporte urbanocinemasfaturasdoaçõesetc

Estado da Arte

PayPass – MasterCard e CitiBank (imagem)uso em estações de metrô

Chiltern RailWays(trens): tíquetes através de celularesBancos

Estado da Arte

BrasilMobility Pass:

gerenciamento de despesas de taxi em ambiente corporativosoutros serviços

Oi PagooCartão de crédito via telefone

M-Ticket Cliente Claro e Visa podem comprar entradas de cinema da rede Cinemark em São Paulo (transmissão do código de barras após pagamento) – usa PPSMS

Mobile Payment API

Literatura RelacionadaEspecificação Java.LangEspecificação JVMJSR-30, JSR-68, JSR-118, JSR-228

Payment API Expert Group – PAPI-EGLíder da especificação – Jean Yves Bitterlich (Siemens)Outros representates: Sony, Symbiam, Nokya, T-Mobile, Aplix, Mtsushita Eletric, etc

Escopo e Requisitos

EscopoDefinir uma API genérica para iniciativas de “PaymentTransaction” de maneira segura e transparente Definir uma sintaxe de descrição de dados de pagamento para suportar diferentes “Adapters”

Escopo e Requisitos

EscopoPermitir que desenvolvedores construam aplicações com controle de produtos e serviços precificados e passíveis de pagamentoPortanto, inclui métodos para:

Requisitar transações de pagamentoRequisitar gerenciamento de preços para produtos e serviçosDisponibilizar serviços de pagamento móvel

Escopo e Requisitos

RequisitosA Payment API é um pacote opcional que roda sob:

CLDCMIDP ou IMP

Não é uma especificação para Aplicações, mas para PaymentModule-PM e Payment Adapaters-PA.

implica que PM e PA podem adicionar outros requisitos fora do escopo dessa especificação• Ex: PPSMS usam JSR-120 e JSR-205

Escopo e Requisitos

RequisitosMIDP x IMP

MIDP oferece interface com o usuárioIMP não oferece interface com o usuário

ObservaçõesNão determina método de pagamentoAPI extras dependem da forma de pagamento

Premium-Price SMS (PPSMS) JapãoVodafon e Cingular possuem SMS Center(SMSC)Wireless API

Tipos de comunicaçãoSMS – Short Message ServiceNFC – Near Field Communication

Arquitetura

A figura mostra os componentes do lado do terminal em uma transação de pagamento

ArquiteturaPanorama funcional e de componentes (EN)

ArquiteturaPanorama funcional e de componentes (PT)

Arquitetura

AtoresApplication: lógica do negocio, recursos da API, pode persistir dados

prover dados no arquivo JAR-Manifest que são injetados pelo comerciante em tempo de deploy

Payment Module: gerenciar um ou mais Adapters, interagir com o usuário final quando necessário, interage com o Adapter, faz a intermediação dos dados provisionados

Payment Adapter: implementa a lógica para processar um pagamento baseado nas requisições do Payment Module, suporta o envio do Payload (dados do pagamento), adota protocolo de comunicação

Arquitetura

AtoresImplementer: desenvolvedor que implementa o módulo de pagamento e ou adaptador de pagamento, em conformidade com a JSR-229Payment Service Provider - PSP: provê informações ao comerciante, dependendo do tipo de pagamento também responde pela confirmação do pagamentoPrice Manager: fixa, atualiza e informa preços aos PSPApplication Provider/Merchant: Homologador e Provedor de aplicações baseada em PAPI

Tem relacionamento com o Price ManagerApplication Developer: Implementa os recursos da JSR-229

Tem relacionamento com o comerciante(merchant)

Arquitetura

Relacionamento de ConfiançaUsuários finais confiam no módulo de pagamento e nos adaptadores quanto ao sigilo das suas informaçõesDesenvolvedores confiam nos provedores de aplicações e nos fabricantes quanto a não alteração das suas implementaçõesO Provedor de APP confia no gerenciador de preçosOs PSPs confiam nos fabricantes quanto aos terminais seguros e compatíveisOs fabricantes confiam nas implementações dos adaptadores

Arquitetura

ResponsabilidadesApplication: gerenciar seu estado internoPayment Module:

responsabilidade = funcionalidades providas e não acessíveis diretamente pela APPProver mapeamento JAR-Manifest Adapter• dados de um APP não devem ser acessados por outra APPSelecionar Métodos• oferecer ao usuário uma forma de selecionar o método desejado• em MIDP isso é simples• em IMP não existe mais de um métodoHistórico das transaçõesInteração de apresentação de erros

Arquitetura

ResponsabilidadesPayment Module: (continuação...)

Atualização de preços e dados

Arquitetura

ResponsabilidadesPayment Adapter:

Encaminhar carga de pagamentos• adota uma carga de até 132 bytes

Prover autenticação de pagamentoInteração de apresentação de erros

Pacote

javax.microedition.payment.

PacoteDesign

Pacote

– Interface TransactionListener

• recebe notificação de registros de transações geradas pelo PM e por conseguinte processadas

• pressupõe que o PM esteja apto a processar uma transação– dados provisionados corretamente

• Método processed() recebe um parâmetro– Registro que mantém o estado da transação

» SUCCESSFUL, FAILED, REJECTED– O registro é identificado pelo ID retornado pelo método

PROCESS() que disparou o início da transação– O registro contém:

» featureID» Estado final» TimeStamp

Mobile Payment API

Interface TransactionRecord• Cada transação é representada por um objeto que

implementa esta interface

Pacote

Classe TransactionModule - TM• Representa a ligação entre a APP e o PM• Cada chamada do método PROCESS() retorna imediatamente

(assíncrono)

Pacote

• Construtor – instancia um objeto TM e verifica se as informações provisionadas estão corretas– parâmetro – o próprio MIDLet ou IMLet

• Métodos:– SetListener() define o listener para eventos assíncronos – Process() tem duas assinaturas

• inicia uma transação para um recurso identificado pelo featuredID configurando no JAR/JAD

• pode gerar exceções• se iniciado, o PM notificará a APP através do listener

quando a transação for encerrada• o listener tem que ser definido antes de chamar esse

método

Pacote

Membros da Classe TransactionModule (continuação..)

– Process() tem duas assinaturas• ao chamar esse método o PM deve interagir com o usuário

apresentando os dados das features bem como datas do provisionamento

• deve pedir confirmação e seleção de método(adapter)• Parâmetros:

– FeatureID, featureTitle, featureDescription– payload – vetor de bytes contendo dados – ex: code activation

de um jogo (pode gerar TransactionPayloadException)• Retorno - ID positivo e único• Exceções

– TransactionModuleException– TransactionListenerException– TransactionFeatureException

Pacote

Membros da Classe TransactionModule (continuação..)

– getPastTransactions(int max) • retorna um vetor de objetos TransactionRecord• o tamanho do vetor é limitado pelo parâmetro max• ordena em ordem crescente• max = 0 nada é retornado

– deliverMissedTransactions() • solicita ao PM para gerar todas as transações perdidas na

interface listener PROCESSED()• não gera duplicida quando chamado mais de uma vez

Provisionamento de dados

Dados são entregues como parte do JAR-ManifestOutros dados podem ser providos pelo JADO MIDLet deve proteger o provisionamento através de assinatura do JAR

para facilitar o desenvolvimento o modo DEBUG dispensa a assinatura


TagMandatório /

Opcional DescriçãoPay-Version M Versão do JAR-Manifest

Pay-Adapters M Adapters registrados. Pode ser uma lista separada por vírgula

Pay-Debug-DemoMode O Valor boleano e se true habilita o modo debug

Pay-Debug- (outros) O Habilita debug específico para ser simular a falha

Arquivo JAD e tags

JAD


TagMandatório /

Opcional DescriçãoPay-Version M Versão do JAR-Manifest

Pay-Update-Stamp M Data do último provisionamento

Pay-Update-URL M URL que aponta para a última versão dos dados de provisionamento

Pay-Cache O Especifica se vai usar cache ou não. Valores possíveis:

[yes|no|<Expiration-Date>].Pay-Providers M Lista de provedores suportados

Pay-feature-<n> M Representa a feature configurada para o adapter - <n> é um número sequencialsem lacunas e começando de ZERO

Arquivo JAR-Manifest e tags

JAR-Manifest


Arquivo JAD - exemplo

[…]Pay-Version: 1.0Pay-Adapters: PPSMSPay-Debug-DemoMode: yesPay-Debug-FailInitialize: noPay-Debug-FailIO: noPay-Debug-MissedTransactions: noPay-Debug-RandomTests: noPay-Debug-AutoRequestMode: accept


Arquivo JAR-Manifest - exemplo

[…]Pay-Version: 1.0Pay-Update-Stamp: 2004-11-15 02:00+01:00Pay-Update-URL: http://<update-site>/thisgame.manifest.jppPay-Providers: TestPay-Feature-0: 0Pay-Test-Info: PPSMS, EUR, 001, 01Pay-Test-Tag-0: 2.40, 4321, 0x123456789abcdef0, 1


Arquivo JAD – exemploUma aplicação cujo provedor suporta SMS e X-Test(adapter proprietário) proverá os seguintes arquivos JAD e JAR respectivamente

JAD

[…]Pay-Version: 1.0Pay-Adapters: PPSMS, X-TESTMIDlet-Permissions: javax.microedition.payment.process.jppMIDlet-Certificate-<n>-<m>: <base64 encoding of a certificate>MIDlet-Jar-RSA-SHA1: <base64 encoded Jar signature>


Arquivo JAR-Manifest - exemplo

[…]Pay-Version: 1.0Pay-Update-Stamp: 2004-11-15 02:00+01:00Pay-Providers: SMS1, Test1Card, Test2CardPay-Update-URL: http://<update-site>/thisgame.manifest.jppPay-Cache: noPay-Feature-0: 0Pay-Feature-1: 0Pay-Feature-2: 1Pay-SMS1-Info: PPSMS, EUR, 928, 99Pay-SMS1-Tag-0: 1.20, 9990000, 0x0cba98765400Pay-SMS1-Tag-1: 2.50, 9990000, 0x0cba98765401, 2Pay-Test1Card-Info: X-TEST8, EUR, c4d21, soap://<soap-site-1>/Pay-Test1Card-Tag-0: 1.21Pay-Test1Card-Tag-1: 2.46Pay-Test2Card-Info: X-TEST8, USD, 8DiU, soap://<soap-site-2>/jsr229

Segurança

No contexto da JSR-229, segurança está relacionada com a garantia do provisionamento de dados, da aplicação e seu estado contra modificações não autorizadas

Trata-se também de garantir que o proprietário do terminal tenha conhecimento de todas as transações realizadas no mesmo

A JSR-229 foi definida e projetada para tirar vantagem dos recursos de segurança e mecanismos de controle previstos pela MIDP2.0.

Segurança

RequisitosResistência a adulteração de:

provisionamento de dados de pagamentosdo estado da informação de pagamentosdo código da aplicação de pagamentos

Proteger :o proprietário do terminal contra sobre-pagamentoo PSP contra acesso fraudulentoo Provedor de Aplicações contra acesso fraudulento

Segurança

Permission NameResistência a adulteração de:

provisionamento de dados de pagamentosdo estado da informação de pagamentosdo código da aplicação de pagamentos

Proteger :o proprietário do terminal contra sobre-pagamentoo PSP contra acesso fraudulentoo Provedor de Aplicações contra acesso fraudulento

Adapters

A JSR faz uma definição do Premium Priced SMS Adapter e faz recomendações de nomeação para novos Adapters

Mostra como o PPSMS devem ser implementados

Adapters

Modelo de pagamento PPSMSBaseado

no número Premium Priced SMS pré-definido pela operadoraou no valor inserido no corpo da mensagem

Essa especificação tanto é válida para SMS-MO (mobileoriginated) como SMS-MT(mobile terminated)

Adapters

Especificação do Provisionamento de DadosADAPTER NAMESPACE - PPSMS

Tag DescriçãoPay-<ProviderTitle>-info Descreve infromações no modelo de provider

<info> - Moeda, MCC, MNCPay-SMS1-Info: PPSMS, EUR, 928, 99

Pay-<ProviderTitle>-tag-<m> The format is <Price>, <PremiumPriced-SMSNumber,<Prefix>,[,NbSMS]Prefix – um vetor de byte que antecede o SMS,uso livreEx:Pay-SMS1-Tag-1: 2.80, 9990000, 0x0cba98765401, 2

Adapters

LimitaçãoFormato 8-bit SMS (máx 140 caracteres)Confiabilidade do Adapter (não é 100%)

Adapters

Exemplo arquivo JAR-Manifest PPSMS

Adapters

Exemplo arquivo JAR-ManifestPPSMS

Bibliografia

http://jcp.org/en/jsr/detail?id=229http://wiki.forum.nokia.com/index.php/API_de_pagamento:_JSR_229http://www.devmedia.com.br/post-10331-Artigo-WebMobile-19-Construindo-Mobile-Payment-com-Java-ME.htmlhttp://download.oracle.com/javame/dev-tools/wtk-cldc-2.5.2-01/UserGuide-html/payment.htmlhttp://innovator.samsungmobile.com/cms/cnts/knowledge.detail.view.do?platformId=3&cntsId=7160

Iniciativas da Industria

payment api (jsr 229)

Technology